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(57) ABSTRACT 

A portable data device system includes a portable data 
device and a cradle for receiving the portable data device. 
The cradle is arranged to recharge the portable data device 
power supply and/or upload or download information to and 
from the portable data device. The cradle and portable data 
device are in wireless communication allowing a minimum 
of processing and data storage capability at the front end and 
hence operation of the portable data device as a thin client. 
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PORTABLE DATA TERMINAL AND CRADLE 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The invention relates to a portable data device or terminal 
and a terminal docking mounting device or cradle. 

2. Description of the Related Art 

Conventional portable data terminals comprise a data 
display, data input means such as a keyboard and data 
storage and processing means. A wide range of applications 
are now available on such terminals including word- 
processing, spread-sheeting, data base applications and so 
forth. Much of the development work in known portable 
data terminals is centred on increasing the data storage and 
processing capabilities. This has led to increases in cost and 
size/weight (and the corresponding need to subsequently 
miniaturise components) together with increased complexity 
leading to increased potential for defect or breakdown. 

In another aspect, U.S. Pat. No. 5,410,326 relates to a 
programmable remote control device for interacting with a 
plurality of remotely controlled devices. The remote control 
device is configured to control a variety of devices and 
carries pictorial icons representing the different functions for 
selection by the user. The device is further configured to 
receive and display advertising messages, and operate vari- 
ous other functions such as electronic mail and order-out 
meal delivery. The system is, however, complex and cum- 
bersome and of limited adaptability. 

U.S. Pat. No. 5,521,370 relates to a hand-held portable 
data capture terminal for example for warehousing, which is 
mountable in a terminal mount for data communication with 
a host computer and/or battery recharging. The specification 
is directed to a data interface between the terminal and the 
terminal mount comprising abutting electrical contact pads. 
The terminal is arranged only to communicate with the 
terminal mount when it is docked therein. The terminal 
carries a processor and memory system serving as a com- 
munication controller and can be arranged to act as network 
controllers when docked. A difficulty with such a system is 
that a considerable processing and memory capability is 
included in the hand-held terminal and that data is only 
downloaded when the terminal is docked in terminal mount. 

U.S. Pat. No. 5,280,621 relates to a control system for a 
personal computer. In conventional personal computers a 
system control processor provided an interface between the 
host processor and peripheral such as a keyboard. System 
performance was limited because of the slow communica- 
tion rate between the system control processor and the 
keyboard, and was further degraded when the system control 
processor handled additional control burdens such as battery 
power management, external bus expansion control and so 
forth. According to U.S. Pat. No. 5,280,621 it is proposed to 
introduce microcontrollers to provide communication 
between respective peripheral devices and the system con- 
trol processor, freeing the system control processor to do 
other tasks improving the overall system performance. 

The question of power management in portable devices 
has been addressed in various manners conventionally. U.S. 
Pat. No. 5,027,294 relates to monitoring the voltage dis- 
charge of a battery power supply in which the user is issued 
warnings at various depletion levels allowing memory back- 
up, avoidance of over-depletion and so forth. U.S. Pat. No. 
5,504,413 recites a battery charging system including feed- 
back input allowing minimisation of overhead voltage 
levels, and connection of a recharging device to a peripheral 
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device via a port at the recharger. U.S. Pat. No. 5,487,181 
refers to power minimisation providing a main processor 
and a lower power processor which allows the main pro- 
cessor to "sleep" except when required. The lower power 

5 processor carries out various minor functions allowing the 
main processor to sleep as far as possible whilst being 
awoken as soon as required. U.S. Pat. No. 5,511,205 relates 
power management in a portable pen-based notebook com- 
puter. The system has a plurality of independently control- 

10 lable power planes selectively powerable to ensure that a 
particular task is performed with minimum power consump- 
tion. In addition separate CPU's operate synchronously in 
relation to one another reducing the amount of processing 
time the main CPU is required to dedicate to the power 

15 management function. 

SUMMARY OF THE INVENTION 

OBJECTS OF THE INVENTION 

20 An object of the invention is to overcome or mitigate 
problems or disadvantages with prior art arrangements. 

A particular object of the invention is to provide a simple 
and reliable portable data terminal. 

25 A further object of the invention is to provide a simple 
reliable cradle for co-operation with a portable data terminal. 

A further object of the invention is to provide a user 
interface between a portable data terminal that is simple to 
use and adapt dependent on the desired implementations. 

30 Features of the Invention 

According to the one aspect the invention relates to a data 
processing system comprising a portable terminal and a 
terminal mount wherein the mount includes a terminal 
interface and processor capability for processing data 

35 received from the terminal and the terminal includes a user 
interface, a mount interface and processor capability suffi- 
cient only to relay user input to the mount for processing and 
data from the mount to the user interface. Thus an ultra thin 
client is provided at the terminal, the mount carrying out the 

40 majority of the computing functions. 

In another aspect the invention relates to a data processing 
system comprising a stand-alone data terminal, docking 
means for docking the terminal and a host network, the 
terminal including a user input and docking means interface 

45 arranged to relay user input to the mount and the mount 
including a terminal interface and a host interface arranged 
to relay the user input to the host, for processing and a 
method of relaying data between a portable terminal and a 
base station comprising the steps of inputting data to the 

50 terminal, relaying the data to the base station with minimal 
processing and processing the data at the base station. 
Optionally, therefore, the majority of the processing power 
can be maintained at the host, allowing a thin docking means 
or cradle. 

55 According to another aspect the invention provides a 
product information retrieval system comprising a portable 
terminal arranged to receive data from one or more data 
output points in a product access zone in which the terminal 
is arranged to display an image of a product to be accessed 

60 in response to data received from the data output point and 
a method of retrieving product information in which a 
portable terminal is provided in a product access zone and 
receives data from one or more data output points, and in 
which the terminal displays an image of a product to be 

65 accessed in response to data received from a data output 
point, and a portable data terminal for operation in an 
operation zone having one or more physical items located at 
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predetermined positions in the zone wherein the data termi- module carries network communication capability for the 
nal comprises a communications receiver and/or transmitter device. As a result transparent network file access is 
and a display arranged to display icon's representative of the achieved. 

physical item and/or its position in the operation zone. This The novel features which are considered as characteristic 

icon based system allows a highly user-friendly, efficient and 5 of the invention are set forth in particular in the appended 
human-error free file system to be implemented. claims. The invention itself, however, both as to its con- 

According to another aspect there is provided a terminal struction and its method of operation, together with addi- 
mount for mounting a portable data terminal, the mount tional objects and advantages thereof, will be best under- 
being adapted for wireless communication with the data stood from the following description of specific 

terminal, wherein the mount is arranged to receive or derive 10 embodiments when read in connection with the accompa- 
display format information for a terminal to be mounted nying drawings. Further features of the invention are set out 
thereon and configure data to be displayed at the terminal in the appended independent claims, and further preferred 
according to the display format. features are set out in the dependent claims. 

According to another aspect there is provided a data 

communications system comprising a portable data commu- 15 BRIEF DESCRIPTION OF THE DRAWINGS 

nication device and a device mount arranged to releasably FIG. 1 shows a terminal and cradle according to the 
receive the device, in which the device mount includes a present invention; 

user identification information input and a device lock CT „ * . , / . - , „ 

, . , . . i . • * * j FIG. 2a is a block diagram of a terminal/cradle arrange- 

arranged to release the device on input of approved user ment . 

identification information and a method of monitoring 20 ' 

access to a portable data communication device wherein the FIG - 26 is a schematic diagram of a terminaVcradle 
portable data communication device is releasably received arrangement; 

in a device mount, a user inputs user identification infer- FIG, 3 is a block diagram of a "thin client" terminal/cradle 
mation to the mount, the mount releases the device if the arrangement; 

identification information is approved and, simultaneously, 25 FIG. 4a is a view of a further embodiment of a terminal; 
commences the timer, the timer is stopped when the terminal FIG. 4b is a plan view of an alternative terminal; 
is reinserted on the mount and the identified user is billed for OT „ . . . - . . . f OT „ A , 

. , . , , . , , . ftPt , FIG. 4c is a side view of the terminal of FIG. 4b; 

the timed period between release and reinsertion of the J 

device. This arrangement is particularly suitable for rental in FIG - 4d & a rear view of the terminal of FIG. 4b; 

a public place such as an airport or retail outlet ("self 30 FIG. 4e is another side view of the terminal of FIG. 4b; 

shopper"). FIG. 4/ is a further side view of the terminal of FIG. 4b; 

The invention further relates to a data communication p IG 5 shows a schematic representation of one possible 

device including wireless communication means for com- use 0 f a terminal according to the present invention; 

municating with one or more access points to a local mG 6 shows a &st ICQN dis x QQ ±t terminal; 

computer network, the device further comprising cellular 35 „ T _ _ . u T ™ T , , . , 

# , u e f - t t ^i_ K _ „ ~_ ■ FIG. 7 shows an alternative ICON display on the terminal; 

telephone means for conventional telephone communication r J 

when the device is out of range of the access points to local FIG - ga shows a ***** alternative ICON display on the 
computer network, a goods transport tracking system com- terminal; 

prising a communication device for a transport vehicle FIG. Sb shows a flow diagram representing operation of 

arranged to log receipt and/or delivery of goods and includ- 40 the terminal; 

ing means for wireless communication with a communica- FIG. 9 shows a battery pack and battery charger for the 
tion network and means for creating a data file accessible via terminal; 

the communication network to provide receipt/delivery FIG. 10 is a block diagram of an alternative terminal 
information, a goods transport tracking network comprising configuration; 

a physical network of transfer points comprising transport 45 FIG n fe ' a scheraatic view Q f an alternative terminal 
vehicles and intermediate stations and a communications configuration; 

network, in which an interface to the communications net- ™„ 1 - . ' _u_„,- „ .„ t - r n f .1 „ 

, . ' j . i. c < . «• 1 1 FIG. 12 is a schematic representation 01 a further appli- 

work is provided at each transfer point and in which the . ft f*u;„, 0 c 0 m 

*\, , • , j ,\ c . t „ cation of the terminal of the present mvention; 

passage of goods is logged at each transfer pomt allowing 4 „ . t . . . . , 

transport information to be accessed at the communications 50 F } G ' 13fl ^ s f schematl f representation of yet a further 
network, a rechargeable battery pack for an electrically application of the terminal of the present invention; 
powered device arranged to be received in a battery charger FIG- 13 *> shows a pendant-type terminal; 
for recharging, in which the battery pack has predetermined FIG. 14 shows a wireless network configuration; 
recharging requirements and includes recharging control FIG. 15 shows a detail of a wireless network configura- 

circuitry for controlling the recharge operation to meet the 55 tion; 

predetermined requirements and a battery recharger for pj G 15 snows a further detail of a wireless network 
receiving and recharging a rechargeable battery pack having configuration; 

predetermined recharging requirements and responsive to FIG. 17 is' a block diagram of an alternative terminal 
recharging control means on the battery pack to control configuration* 

recharge operation to meet the predetermine recharging 60 M ^ & ^ d of an ^ 

requirements. fit*- 

The invention further provides a data device arranged to c0 ^ r f ft l0n ' . 
communication with a communication network including an FIG - 19 * a block digram of yet a further alternative 
adapter module interface and an adapter module in which cradle configuration; 

the adapter module carries network communication capa- 65 FIG - 20 shows software data and control flow in the 
bility and an adapter module for a data device communi- terminal; 

eating with a communication network in which the adapter FIG. 21 shows software data and control flow in a cradle; 
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FIG. 22 is a block diagram showing components of an may represent input data for checking purposes, or carry 

embedded storage device; instruction or error messages for the user, or even commu- 

FIG. 23 is a block diagram showing a configuration of an nication messages transmitted from remote points. The 

alternative storage device; dis P lav driver drives me dis P la y ™ 6 receives display 

nr* *>a - uiij- u • *u a r 5 instructions from the processor, 

FIG 24 is a block diagram showmg the configuration of can * CRT type television display, a flat 

yet a further alternative storage device; pane] LCD type display of sui , able ^ 

FIG. 25 is a block diagram showing operation of a advantage of flat panel displays is of course the low bulk 

standard Client Device and File Access Card; complementary to the compactness of the terminal as a 

FIG. 26 is a block hardware diagram of an alternative 1Q whole. 

Client Device and File Access Card system; A remote link 22 is provided allowing communication 

FIG. 27 is a software block diagram of the alternative File between terminal 10 and the cradle 12 (or indeed any other 

Access Card system* access point as defined by the operational parameters of the 

FIG. 28 shows a hardware model for a web-enabled system) by m 

. , IRDA, microwave, RF or any other suitable method. Data to 

ermin ' „ rrTw 15 and from the remote link is processed by the processor 24. 

FIG. 29 shows a task structure for the arrangement of HO. ^ processor 24 can comprise any standard processing 



28; 



system such as a CPU. The processor allows centralised 



FIG. 30a shows a transparent web server; control of the other components as discussed above and 

FIG. 30b shows a transparent web server card; below, together with general operational conditions of the 

FIG. 31a shows browsing in relation to the transparent 20 terminal, data and power checks, compatibility checks and 

web server- so forth ^ appropriate. 

FIG. 316 shows another aspect of browsing in relation to J*™^"* 1 ' ^ ^ ™l* * * £ 6, 

4 . 4 , r although this may be incorporated m the same unit as the 

the transparent web server; processor 24. The memory 26 allows long or short term data 

FIG. 32 shows an alternative mventive battery pack; 2 5 storage for example of data received at the user or other 

FIG. 33a shows an improved battery pack arrangement; input 16, 18, via the remote link 22 or, as discussed in more 

and detail below, via the cradle interface. Memory control, 

FIG. 336 shows an alternative improved battery pack to management and transfer can be controlled by the processor 

that shown in FIG. 33a, in cut-away form. 24. 

30 The cradle interface 28 allows downloading of data stored 

DETAILED DESCRIPTION OF THE in the terminal 10 to the cradle 12 as well as transfer of 

PREFERRED EMBODIMENTS control or other data from the cradle 12 to the terminal 10. 

™™ - ^ . L *r*i_ Information to and from the cradle interface 28 is processed 

FIGS. 1, 2a and 2b show the basic components of the ^ ^ 24 ^ riate , M discuss J in more 

system according to the present invention. A portable ter- bc , {h& cradle/terminaI interface fa a physical 

minal 10, for example a hand-held computer of the personal which operates during, and can be enabled by, 

digital assistant type which can optionally carry scanning/ msert ion of the terminal 10 into the recess 14 of the cradle 

barcode reading capabilities is arranged to interface with a 12. 

cradle 12 via a physical connection. For example the termi- ^ cradle u also i nc i udes various components shown in 

nal 10 is inserted into a suitable recess 14 in the cradle 12. bkKk form ^ nG ^ both arranged to deal ^th control 

The cradle 12 is itself connected with a host system 15 and communication with the terminal 10 as well as com- 

which can be a stand-alone computer, or part of an Intranet/ mun i ca tion with the host and other peripheral functions. 

LAN or Internet/WAN. ^ cradk u ]nchldGS a proC essor 30 for controlling the 

The basic components of the terminal 10, 12 cradle and remaining components as discussed below as well as opera- 
host 15 are standard and interconnected in standard ways 45 tional conditions of the cradle 12 and general communica- 
using known interfaces and communication protocols except tion needs between the crad i e 12 and the terminal 10, 
where otherwise indicated below. Accordingly full hardware betW ecn the cradle 10 and the host 15 and, where the cradle 
details of the components are not discussed in detail here as acts transparently, between the terminal 10 and the host 15. 
they will be well known to the skilled reader. A brief The cradle c ^ itlternal memory 32 and 
discussion of the various components and their uses and 5o extemal me 34 ^ of these are for stQrage of 
interconnections is provided below, however. information received from the host 15 and/or terminal 10 for 

As shown in FIG. 2a the terminal conventionally com- transfer between the two, as controlled by the processor 30. 

prises a user input 16, an "other input" 18, a display driver internal memory can, for example, comprise part of the 

20, a remote link 22, a processor 24, a memory 26, and a processor unit 30. The external memory 34 preferably makes 

cradle interface 28. 55 use 0 f external storage devices such as disks etc. 

The user input 16 can comprise, for example, a keyboard The crad i e 12 communicates with the terminal 10 by 

with which the user can input information to the terminal. virtue of a terminal interface 36 communicating with the 

The user input is transferred to the processor and further crad i e interface 28. The terminal and cradle interfaces are 

processed as discussed below. preferably physical interfaces as discussed above. Informa- 

The "other input" 18 can comprise, for example, a bar- 60 tion to and from the terminal 10 can be controlled via a 
code scanner or other reader, video camera input, audio processor 30. The cradle 12 further comprises a host inter- 
input or any other appropriate data input. FIG. 1 shows a face 38 for communicating with the host 15. The interface 
terminal 10 including a swivel mounted barcode reader head can be a wired interface or a wireless interface of known 
18. The input information is transferred to the processor 24 type as appropriate. A communication controller 40 can also 
for further processing as discussed below. 65 be provided additionally to control the various communica- 

The terminal 10 preferably includes a display 19 for tion protocols between the terminal 10, the cradle 12 and the 

displaying information to the user. For example the display host 15. 
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A remote link 42 is provided in the cradle 12 for com- 
munication with the remote link 22 in the terminal 10. The 
communication can, as discussed above, be any wireless 
means of communication such as infrared IRDA, radio or 
microwave. 

The cradle 12 can also include various peripherals of 
standard types found with computers generally such as a 
printer 44 or other component such as an enlarged display, 
a modem link to a remote host, additional storage or 
processing capacity and so forth. 

The cradle 12 communicates via the host interface 38 with 
the host 15. The host 15 can be a stand-alone computer or 
part of a local area network such as the Intranet. The Intranet 
can itself be part of the Internet or another wide area 
network, and if appropriate suitable security measures such 
as a "fire wall" can be put in place. 

Numerous applications and advantages are provided by 
the system shown in FIGS. 1, 2a and 2b. In particular, all of 
the advantages of a hand-held terminal are available, such as 
portability, ease of use, and suitability for mobile uses. 
Particular applications include inventorying, monitoring of 
transported goods, point of sale use, stock exchange 
formulations, auctions and so forth. Because the cradle 
includes a data interface, information input to the terminal, 
for example as keyboard input or barcode input can be stored 
short-term in the terminal and transferred at regular intervals 
to the cradle when it is inserted in the cradle. Once the 
information is downloaded the memory in the terminal can 
be cleared. At the same time control or application data can 
be transferred from the cradle to the terminal such that the 
terminal application can be changed or updated as desired. 
The cradle further preferably includes a battery charging 
module which connects with the terminal when it is inserted 
into the cradle to allow simultaneous battery recharging. 
This option is discussed in more detail below. 

The cradle then communicates the downloaded informa- 
tion to the host, and allows communication of update/ 
application information from the host to the terminal. 

Accordingly the system allows rapid updating of the host 
data base with information from the terminal whilst requir- 
ing reduced memory capacity in the terminal. At the same 
time the cradle allows significant time-efficiency benefits, 
both in reducing user involvement in data transfer to a 
minimum and in allowing the utilisation of user down-time 
to download information. The remote link further allows 
immediate update capability where necessary, at the same 
time allowing this capacity to be kept to a minimum (by 
virtue of the regular downloading sessions) giving rise to a 
corresponding reduction in power drain. 

As discussed in more detail below, particular benefits of 
the invention lie in a system in which the basic system 
described with reference to FIGS. 1, 2a and lb is enhanced, 
and memory/computing tasks distributed so as to allow 
maximum flexibility and minimum demand on the terminal 
10. Known hand-held computers are continually being 
updated and redesigned to allow maximum memory 
capacity, data storage and application availability. Generally 
this involves increasing the cost and complexity of the 
system, and will lead to increases in weight and bulk which 
is of course undesirable in a portable system. In addition the 
overheads on the system are very high — updating of the 
computer is costly and must be done on an individual basis, 
and based on added peripherals or software that will carry a 
considerable cost burden. This tendency to increased, inter- 
nal capacity and capability leads to a greater risk of defect 
or error and the attendant disadvantages. Such systems are 
currently known by the term "fat clients". 
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The present invention, on the other hand, allows an 
"ultra- thin client". In principle, this is achieved by reducing 
the computing and memory burden in the terminal to the 
greatest possible extent and incorporating that burden 

5 instead within the cradle or, if possible, in the host itself. 
This also allows the cradle 12 to operate as a "thin client". 
As a result the terminal includes the minimum capacity for 
user interface, including the display capacity, user or other 
input capacity, minimal memory and processing capacity 
and the communications capacity discussed above. The 
cradle/host thus acts as the true computer, carrying a major- 
ity of the processing and memory capacity, including disk 
drives, communication interface and so forth. Because the 
cradle acts as a thin client, its simplicity and adaptability can 
be maintained by ensuring that as much processing as 

15 possible is carried out at the host. 

A basic architecture allowing an ultra-thin client is shown 
in FIG. 3. Similar reference numerals are used to depict 
similar features throughout the specification and explanation 
of the various features will not be repeated in detail except 

20 as appropriate. 

It will be seen that the terminal 10 still supports various 
basic capabilities to the same extent as the version shown in 
FIG. 1, in particular the user and other inputs 16, 18 and the 
cradle interface and remote link 28, 22 must retain many of 

25 their features in order that the terminal 10 can perform its 
basic front-end functions adequately. However, the 
processor, memory and display driver are all consolidated 
into a single, lower specification unit, once again sufficient 
to drive the required front-end functions adequately. Man- 

30 agement of the transferred functions is therefore handled by 
the cradle and/or host. For example, processing of the data 
input to the terminal can be carried out by the cradle after the 
information has been downloaded, such that the terminal 
needs to carry and store only raw data, requiring less 

35 memory space and processing power. The cradle also oper- 
ates as the client in terms of external data storage and 
peripheral applications such as printing and display. The 
cradle 12 then communicates with the host 14. Significantly, 
however, the host itself provides applications support as 

40 discussed in more detail below. In addition the host can take 
on more of the cradle functions as appropriate if it is desired 
to reduce the cradle specifications, as long as the cradle 
retains it basic downloading and intermediary functions. 
Returning once again to conventional "fat clients", appli- 

45 cations to be run by the terminal such as business applica- 
tions for objects to be accessed, data base, file, mail, printing 
and directory services and other dedicated functions are 
provided internal to the terminal itself. This necessitates 
considerable memory and processing requirements, added 

50 complexity and bulk and the need for regular updating and 
quite possibly servicing. 

The present invention, however, operates according to a 
different system, the applications discussed above such as 
data bases, mail delivery or further alternatives such as 

55 inventorying systems, pricing/coding systems, spread- 
sheeting and word-processing applications are stored neither 
on the terminal, nor on the cradle, but on the host to which 
the cradle has access. These applications are provided and 
maintained by a central server or distributed servers on the 

60 host network as appropriate, allowing central control updat- 
ing and maintenance. In addition multiple copies of the 
application software are not required for permanent storage 
on a large number of independent terminals which would 
give rise to yet further software License cost burdens and 

65 maintenance and updating difficulties. 

When it is desired to make use of a specific application, 
that application can be called up at the cradle and cached for 
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dynamic use, and deleted when it is no longer needed. As a 
result the amount of memory required is considerably 
reduced. For example, where it is desired to process data 
input to the terminal following a specified application, the 
application can be called up from the host and processed at 
the cradle 12, and the results stored in the internal or external 
memory, printed out, displayed in a suitable display or 
downloaded to the host for further processing. In a further 
alternative the data from the terminal can be transferred 
from the cradle to the host as raw data with instructions to 
the means of processing and processing carried out at the 
host, reducing the memory and processing burden on the 
terminal and cradle yet further. 

As discussed above, there are numerous applications for 
the system of the present invention, for example in trans- 
portation and logistics fields, warehouse facilities, public 
safety, retail and any other enterprise relying on fast and 
efficient data flow and requiring portable data collection and 
transmission. As will be discussed in more detail below, one 
possible cradle implementation comprises a vehicle based, 
wireless cradle communicating with access points via wire- 
less communication. This allows vehicle based use, yet more 
suitable for transportation in courier companies, utilities, 
public safety organisations, field sales and service and any 
other mobile operations. 

One possible embodiment of the terminal according to the 
present invention is shown in more detail in FIG. 4a. The 
terminal 10 is preferably shaped with ergonomic consider- 
ations in mind allowing easy use, carrying and storage by the 
user. A significant feature of the terminal is the display 50. 
This may be an LCD or video display, for example. It is 
preferably of high resolution, sufficient to show detailed 
icons and, preferably, detailed video images as discussed in 
more detail below. The terminal 10 carries functions suitable 
for laser scanning and/or pen-based data collection. For 
example the terminal 10 can include a reader component 52 
which can be integral as shown or modular. The reader 52 is 
arranged for laser scanning of graphic indicia such as 
barcodes and includes the basic component features of a 
reader, namely a reading beam emitting means such as a 
laser diode, a reflected reading beam detecting means and 
means for scanning the beam if that is desired, for example 
an oscillating mirror (in the case of a "flying spot" optical 
scanner). If the scanner is a "field of view" scanner, on the 
other hand, no scanning means is required, and the detector 
comprises a CCD (charge coupled device) array. Data col- 
lected by the reader 52 is treated as "other input" shown in 
block 18 of FIGS. 2a and 3 in relation to the terminal, and 
the data is processed accordingly. 

In addition the terminal 10 can include a data pen 54. Such 
features are known in the art. In particular the data pen 54 
can be used to write directly onto the display 50 of the 
terminal 10, either for data entry, for signature capture and 
verification or other appropriate data collection and verifi- 
cation purposes. The terminal 10 also includes an audio 
speaker 56 allowing alarm signals and/or other audio mes- 
sages such as voice synthesised speech or human voice to be 
output by the terminal to the user, as well as an audio input 
such as a microphone for example for two-way voice 
communication. 

FIGS. 4b to 4/ show an alternative terminal implementa- 
tion 45. The terminal 45 includes a display 46, controls 47a, 
41b and a speaker 48. The terminal is arranged for wireless 
communication with, for example, a local Intranet network. 
Messages to the terminal 45 are displayed on the display 46. 
Simple messages can also be relayed from the terminal 45, 
alternatively the terminal 45 can relay basic information as 
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to location or user identification. Preferably the display 46 is 
an ICON based display in which, for example, the user is 
able to select messages to be relayed to the network by 
scrolling between suitable icons using control buttons 47a, 

5 41b. The terminal 45 can also include audio capability either 
emitting a short "beep" type signal when a message is 
received or, in more sophisticated versions, incorporating a 
voice synthesizer which can notify the user that a message 
has been received or indeed speak the message. The terminal 

10 45 can also include a microphone (not shown) allowing 
audio messages to be relayed to the network via the terminal 
45. For ease of use the terminal preferably also includes a 
clip 49 allowing it to be releasably attached to a user's 
clothing. 

15 The system preferably incorporates power management/ 
distributed power management to ensure that, for the por- 
table components at least the power supply is as efficiently 
used as possible ensuring that the full life of a power supply 
is obtained. In particular where the terminal is capable of 

20 performing different tasks using different components, the 
power usage for each component is preferably distributed by 
individual adjustment in relation to each component to 
optimise power demand to meet the necessary power 
requirements. 

25 A retail application of the invention is shown in FIG. 5. A 
customer 60 enters a retail outlet such as a supermarket (as 
shown), or any other suitable store selling merchandise or 
products. The retail outlet automatically provides a plurality 
of portable terminals 10 stored at a convenient location in 

30 their respective cradles 12. The customer 60 selects a 
terminal 10 from a cradle 12. As shown the retail outlet sells 
a variety of products for example at shelves 62 or counters 
64. Also provided in the retail outlet are a plurality of radio 
or other suitable wireless transmitters or access points 66, at 

35 appropriate locations. 

As the customer 60 moves about the retail outlet the 
access points 66 broadcast to the terminal 10. The terminal 
10 uses known prioritising systems and/or algorithms to 

4Q accept signals only from the nearest access point 66. The 
access point 66 transmits information concerning products 
available in the locality of the terminal 10 for display on the 
display 50. The terminal 10 receives the signals via the 
remote link 22 shown in FIG. 2a. 

45 The information transmitted by the access point 66 to the 
terminal 10 can take various forms, and in one preferred 
embodiment the terminal displays graphic icons represent- 
ing products available in the locality, as shown in FIG. 6. For 
example where the consumer is in the vicinity of the laundry 

50 section and the terminal 10 selects the broadcast signal from 
the nearest access point 66, products available in the laundry 
section can appear on the terminal display 50 such as 
dishwashing or normal washing up liquid, 70, 72 respec- 
tively. Actual pictorial representations of the products can 

55 appear for the customer's ease of reference. Accompanying 
information such as price, location and any special offers can 
also be provided at 74. Accordingly, the retail environment 
can be tailored for optimum efficiency. 

Either a dedicated access point 66 or each of the plurality 

60 of access points 66 can also provide, for example, a map of 
the retail outlets and the products found as shown in FIG. 7. 
Optionally the map could include a marker 76 indicating the 
current location of the user — this could be approximated by 
establishing which access point was currently in communi- 

65 cation with the terminal, or a simple geometric positioning 
system could be used. Indeed such a positioning system 
would further allow broadcasts to the terminal to be depen- 
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dent upon the customer's position as established by the 
positioning system rather than as determined by the location 
of the closest access point. 

The terminal can include a preliminary option screen, as 
shown in FIG. 8a, which is displayed to the customer when 
the terminal is first accessed. Various icons are shown 
depending on what functions the customer wishes to utilise. 
The icons can be accessed and processed by the customer in 
various known ways, for example by using an integral 
"mouse" type roller on the scanner, by having a touch- 
sensitive screen, by having a "digital pen" arranged to 
interact with the screen or by using a keyboard on the 
terminal. The icons can include the following: personal 
identification information entry 80, map 82, product infor- 
mation 84, current offers 86, products in the user's vicinity 
88, terminal parameters 90, depiction of a local shelf 92 and 
help 94. It will be appreciated that many other icons and 
functions can be incorporated as will become apparent from 
the following discussion. 

Operation of the initial screen and the subsequent screens 
is represented by the flow chart shown in FIG. 8b. At step 
100 the terminal is removed from the cradle which auto- 
matically initiates presentation of the option screen. The 
terminal then awaits selection of a given option at 102. The 
system then moves to the sub-menu required by the icon 80 
to 94. 

If the personal identification information entry icon 80 is 
selected then the terminal awaits entry of the relevant 
information. This can be, for example, by entering a credit 
card or other identification number, by swiping a suitable 
magnetic swipe card through a slot in the terminal, or by 
using barcode capabilities on the terminal to read barcoded 
personal ID information. This is shown generally at 104. 
Once the information is entered automatic crediting or 
debiting of items scanned and purchased by the customer 
can be initiated, or additional information concerning the 
customer's buying patterns and preferences can be utilised 
to target the customer with selected product advertisements. 
The information can be relayed from the terminal to the 
access points via wireless communication. Alternatively, the 
user identification information can be entered while the 
terminal is in the cradle, for example via a swipe slot on the 
cradle. Indeed this can be used to release and initiate the 
terminal as an additional security measure. Once the infor- 
mation has been entered and processed as appropriate at step 
106 the system returns to the menus screen at 102. 

If the map option is selected then, optionally, the user's 
current location is identified at 110 and the map is displayed 
showing this information at 112. The customer then has the 
option to return to the initial menu at step 108. 

Where product information is required at 84, the required 
product can either be typed in or can be selected using a 
series of menus descending in scope — 114 to 116. Once the 
product is identified then the customer can be presented with 
various options as to what information is required — price, 
brands available, offers available, location and so forth at 
118. The user can also return to the main screen 102 at step 
108. 

If the customer wishes to view current offers, at 86, then 
the offer type of interest can be selected at 118. For example 
all current offers can be scrolled past the user, offers linked 
into purchases that the user has already made can be shown, 
offers relating to a particular class of goods can be shown, 
or offers in the vicinity can be shown as selected by an 
appropriate icon or data entry. The user can then return to the 
main screen 102 at step 120. 
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If the user wishes to find out what products are available 
in the vicinity then the user location is established at 122 and 
broadcast signals from the relevant access points 66 received 
and displayed at 124. This option may be maintained in 
5 default to present suitable information to the customer as the 
customer proceeds around the retail outlet. Once again the 
customer has the option of returning to the main screen 102 
at step 126. 

If the customer wishes to select terminal parameters at 

10 step 90, the various parameters available are displayed at 
step 128. Those parameters can be, for example, display 
brightness, display size, language, volume (where a voice 
synthesizer is incorporated) and so forth. The parameter is 
adjusted as appropriate at step 130 and the user can then 

15 return to the main menu 102 at step 126. 

Where the "local shelf icon 92 is selected, the closest 
shelf can be selected depending on the customer's location, 
and the shelf displayed pictorially. For example where the 
customer is trying to find a specific product, the product can 

20 be highlighted. This option can be used in conjunction with 
the map system to identify a given shelf as shown by the 
flashing sign 134 in FIG. 7. Alternatively, the shelf repre- 
sentation could highlight products with offers on or any 

^ other relevant information, at step 132. 

If the help icon 94 is selected then the customer is then 
invited to select which of the icons he requires further 
explanation on at step 136. The appropriate help message 
138 is then displayed accordingly. For each of the options, 

30 the customer has the option to return to the main screen 102. 
It will be seen that the system offers a very user-friendly 
layout allowing the customer to identify products, find out 
where the products are in relation to the customer, become 
aware of special offers and so forth. Where customer iden- 

35 tification information is stored then the customer can be 
targeted with marketing/advertising information tailored to 
his specific stored preferences. The system can be yet further 
improved by incorporating a voice synthesizer or other 
audio message means in the terminal such that the terminal 

40 can "speak" to the customer to pass on information con- 
cerning various products of interest and any other relevant 
information. 

The system can also have application in inventorying and 
stocking of the outlet (or indeed for warehousing and so 

45 forth although the following discussion is limited to the 
retail outlet discussed above). For example, where it is 
desired to re-stack the shelves a shelf in its current form can 
be shown on the screen and re-arrangement could be carried 
out virtually first by dragging and dropping the relevant 

50 graphics to show the movement of the actual goods on the 
shelves. The physical moves could follow. This would allow 
both a guide as to how the re-stacked shelves will look and 
also a very helpful check to ensure that shelf stackers were 
able to compare the steps they had taken with those that were 

55 required. Alternatively, for a given product or brand name or 
class of products, by highlighting the representation of that 
product on screen, relevant data such as inventory, delivery, 
sales history and so forth could be presented to the user. A 
similar system of icons and steps could be used to those 

60 discussed with reference to FIGS. 8a and 8b. Dedicated 
terminals could be provided for these purposes in the retail 
outlet discussed above. Alternatively, the shelf stacker, 
inventory officer or other relevant personnel could enter 
their user identification information to the cradle prior to 

65 removing the terminal such that the terminal is initialised 
appropriately. It will be appreciated that the same system 
could be used for inventorying in warehouses or general 
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product tracking, using graphic icons to represent the prod- 
ucts and allow quick, user-friendly accessing of background, 
ordering or destination information. 

It will be seen that a variety of other peripheral features 
can be envisaged for the system. For example the system can 5 
include a range alarm such that if a terminal is taken outside 
the store, or outside the designated area within the store, an 
alarm will sound. For example if the customer carrying the 
terminal strays into an area where no access points are 
available or where access is generally restricted to staff then 10 
the alarm can sound. The alarm is provided within the 
terminal and can operate, for example, on the basis of range 
signals from the closest access point to establish whether it 
has exceeded that range in which case the alarm will sound. 

The terminal can be used in conjunction with a "self- 
scanning" system by the user whereby the user scans those 
products purchased personally, removing the need for 
check-out personnel and generally accelerating the shopping 
process. In that case the terminal can store the purchasing 
details against the user identification information — where 
appropriate — to update data bases on the particular custom- 
er's marketing profile. The scanner can also be used to read 
codes directly from products in order that additional infor- 
mation can be called up at the terminal. 

The system described above is particularly useful for 
"ultra thin" clients in the form of portable terminals. The 
basic capabilities that must be carried on the terminal itself 
are the display driver, minimal memory and processing 
requirements and communications capabilities and protocols 
for communication both with the access points and the 
cradle. Information concerning products, maps and other 
relevant aspects can be accessed on demand via the access 
points from a host. Data stored concerning a given custom- 
er's buying patterns and, as appropriate, queries and other 
transactions can be downloaded to the cradle after each use, 
reducing the memory requirements considerably. Similarly, 
the exact functions required for the terminal e.g. customer 
use, inventory use, re-stacking use and so forth can be 
loaded from the cradle once the use has been identified 
whilst the terminal is still stored in the cradle. As a result the 
memory and processing burden on the terminal itself can be 
kept to a minimum, allowing simplicity and reduction in 
costs, as well as ease of updating applications and so forth. 

In an alternative arrangement each terminal can commu- 
nicate with its respective cradle if the store is of suitable size. 
Accordingly the ultra-thin client-thin cradle implementation 
can be achieved. 

The system can be yet further enhanced in various man- 
ners. For example the terminal could incorporate a detach- 
able scanner portion, such that the scanner and/or terminal 
are each autonomous and independently accessible. In some 
circumstances the capabilities of the terminal itself or the 
scanner itself will only be required and the additional burden 



page to fit the screen without the requirement for "wrap- 
around", that is, an intended single line of text being split 
into two or more lines. As an alternative to automatic 
formatting, a predetermined selection of available pre- 
defined format options could be accessed, and the suitable 
option adopted. An alternative method of avoiding wrap- 
around for text lines would be to scale the text down to 
create a smaller typeface size allowing a single line accom- 
modated without wrap-around. 

In addition to its downloading/uploading/initialising, 
security and storage capabilities, another important function 
fulfilled by the cradle is a battery recharging function. 
Whenever the cradle receives a terminal, a battery level 
check is carried out and if the batteries are below full power, 
or a predetermined threshold power level then recharging 
will automatically take place during the down time of the 
terminal. The terminal carries suitable contacts arranged to 
mate with charging contacts on the cradle itself in a known 
manner. Battery recharging technology will be well known 
to the skilled person and is not described in any detail here. 

A charging configuration is shown in FIG. 9. According to 
this configuration the terminal 10 includes a rechargeable 
battery pack 1010 which is removably insertable into the 
terminal and includes suitable powering contacts 1012, 1014 
to cooperate with corresponding contacts in the terminal 10. 
The battery pack 1010 includes a plurality of power cells 
1016 which are either permanently retained in the battery 
pack 1010 or replaceable to prolong the life of the battery 
pack as a whole. The battery pack 1010 is received in a 
charger 1020 which has one or preferably a plurality of 
battery pack receiving slots 1022, 1024, 1026. The charger 
1020 is powered from a suitable power source shown 
schematically at 1028. This system allows multiple battery 
packs to be recharged at the same time, such that a plurality 
of terminals can operate on a fully charged battery pack 
whilst a replacement battery pack is being charged. This 
decreases the down time of the portable terminals to an 
extent limited only by the availability of battery packs and 
chargers. 

The charger 1020 can be incorporated in a cradle or 
40 provided separately as appropriate. 

It is necessary in any such arrangement to introduce 
adapter circuitry which determines the charging rate and 
other parameters dependent on the nature both of the battery 
pack and the charger. Conventionally such adapter circuitry 
45 is provided in the charger itself, reducing the weight and 
complexity of the portable battery packs accordingly. 
According to an aspect of the present invention, however, 
the adapter circuitry is provided on the battery pack itself for 
example on a bottom face as shown schematically at 1030. 
According to this system charging operation and charger 
1020 design are greatly simplified. In particular the battery 
pack 1010 can be inserted into in the appropriately config- 
ured charger and the adapter circuitry 1030 provided on the 
battery pack 1010 adapts operation accordingly. The user 
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of the other components would not be desired. This would 55 therefore does not have to spend time ensuring that the 

be the case for example where a portable digital assistant correct charger 1020 has been selected. Yet further enhance- 

was required. ments of the terminal are discussed in the following para- 

A further possibility would be that of adapting the display graphs, 

format of the terminal. This would preferably be incorpo- In a further revised variant shown in FIG. 32 each battery 

rated as a software facility in the cradle, rather than bur- 60 pack 600 is provided with an adapter 602 which receives in 



dening the terminal with the capability. The display 
format — i.e. the number of characters in the horizontal 
direction — could be adapted to the horizontal length of the 
screen of the terminal. To make the system as user-friendly 
as possible it would preferably be the case that the terminal 
communicates the display dimensions to the cradle such that 
the server/cradle could automatically format the display 



65 



a suitable recess such as that shown at 604 all or a portion 
of the battery pack 600. In the embodiment shown the 
battery pack 600 includes a projecting connecting portion 
606 which is received in the recess 604 of the adapter 602. 
The connecting portion 606 and recess 604 have comple- 
mentary contacts shown generally at 608 for power supply 
and so forth. 
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The adapter 602 is received in a base unit 610 and 
provides a suitable interface between the battery pack 600 
and the base unit 610. Complementary contacts shown 
generally at 612 are provided on the adapter 602 and an 
adapter receiving recess 614 on the base unit 610 for power 
transmission and so forth. 

The adapter 602 carries all charging electronics except the 
power lines themselves. Accordingly control of the charging 
process is achieved as discussed in more detail above. The 
adapter 602 can carry indicators such as LED's shown 
generally at 616 to indicate charging completed, error, 
charging in progress and so forth. 

It will be seen that the base unit 610 is a multi-slot unit 
allowing the charging of a plurality of battery packs via 
respective adapters simultaneously. The base unit 610 can 
work off an internal power supply 618 or an external power 
supply 620 as appropriate. 

If it is desired to charge only a single battery pack then the 
adapter can further carry a power supply connector for 
connection directly to a power supply. As a result, in those 
circumstances, the base unit 610 is not required at all. 

According to yet a further variant, it is known to provide 
"smart" batteries including complex electronics such as 
EEPROMS, input/output and so forth. These smart batteries 
communicate with the charger or other host to provide 
various parameters including gas gaging, status of charge, 
cycle number and so forth. The smart batteries, however, add 
considerably to the cost of a pack and at the end of the 
limited life cycle of the cells (usually a few hundred cycles) 
the whole "smart" battery pack must be disposed of. 

This can be overcome by using a battery pack 1010 of the 
type shown in FIG. 9. In this case the cells 1016 are 
replaceable, the smart electronics being kept in the battery 
pack 1010. For example the cells can be accessed through a 
door or cover as appropriate. As a result the expensive 
electronics and costly battery pack housing can be saved and 
used repeatedly. 

FIGS. 33a and 336 illustrate yet further variants to battery 
pack/charger arrangements. In known systems, battery packs 
are charged by miniature chargers which are either incor- 
porated into the large outlet plug-type of a housing or in a 
plastic module which is externally attached to the battery 
pack. Both solutions require, external to the battery pack, 
either cord or module parts. In the arrangements shown in 
FIGS. 33a, 33b, any such external charging device to charge 
the batteries is eliminated by providing a battery pack 630 
including, as shown generally at 632 in FIG. 33b, a charger 
component such as an AC/DC convenor, charge electronics, 
gas gage, all incorporated as permanent components. Two 
alternative types of battery package 630 are proposed. In 
FIG. 33a the pack is disposable after the individual cells (not 
shown) reach their lifetime limit. In FIG. 33b it will be seen 
that the battery pack 630 includes, for example, a hinged 
cover 634 (on which the retractable plug 636 is optionally 
mounted) allowing the cells 638 to be replaced after they 
reach their life limit. It will be seen that the battery pack 630 
as shown in FIG. 33b includes suitable contacts 640 against 
which the cells 638 can be mounted for operation of the 
battery pack 630. 

In one embodiment it may be desired to allow "renting" 
of the terminals — for example where use of the terminals is 
at a premium and optional. The cradle carries a physical lock 
on the terminal and/or some form of power/access lock such 
that, without authorisation, the user cannot release the 
terminal from the cradle, or cannot use the terminal. Autho- 
risation can be obtained by suitable user identification, for 
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example swiping a credit card or other user identifying 
means through the cradle. If authorisation is given the lock 
is released and the user can remove and use the terminal. At 
the same time the release time is clocked so that the user will 

5 be billed for the rental time until the terminal is returned to 
the cradle at which time the timing clock will cease to 
increment. Billing can be carried out automatically, where 
appropriate, to the user's credit card. One capability that the 
terminal could incorporate would be as a portable telephone 

10 or "cellphone" in which case the terminal/cradle would be a 
marketing tool for renting cellphones for a period of time. 
Whatever the desired use, operational checks can be carried 
out by the cradle when the terminal is returned to it to ensure 
that it is operative and has not been damaged during the 

15 rental period. If damage has occurred then the user will be 
identified by the identification information and can be billed 
appropriately. In addition information can be stored such 
that, in future, the user is not authorised to use the terminal 
or only at a premium rate. 

20 In cases where the terminal is, or incorporates a cellular 
telephone an automatic facility can be provided in which the 
terminal/telephone operates over a wireless LAN as a pre- 
ferred default option, but if the terminal is out of range of the 
access point (as defined by a predetermined level of com- 

25 munications reliability) the system uses the cellular tele- 
phone capability. Accordingly, the user can connect to the 
desired destination even if he moves outside the wireless 
LAN area, making the calling network transparent to the 
user whose only concern is that guaranteed communications 

30 are provided. 

It is further desired to allow individual portable terminals 
to network with one another. This networking can be carried 
out using any suitable protocol, for example the system set 
out in the article "Routing in Ad-hoc Networks of Mobile 

35 Hosts", David B. Johnson, 1995 IEEE Pages 158-163. In 
particular a protocol specific to the network of mobile hosts 
is required taking into account the mobility of the hosts and 
the limited transmission range. A source host finds a route to 
a target host via intermediate hosts by broadcasting a query 

40 packet which records its route to the target host. The request 
pack carries a request identifier so that intermediate hosts 
ignore all but the first copy of the request packet. The total 
number of steps is limited. As a result the shortest path can 
generally be found with a minimum of communication 

45 overhead. Although the routes are discovered this way, the 
route may also be maintained and problems can arise where 
one of the intermediate hosts in the selected route moves out 
of transmission range. To overcome this route maintenance 
is carried out using a hop-by-hop acknowledgement system 

50 such that if there is a transmission problem this is reported 
back to the original sender and the route discovery system 
recommenced. 

It is also desirable, in a mobile computer network, to 
ensure that the current location of the mobile terminal is 

55 known, not least for the reasons discussed above in relation 
to message routing. One method of doing this is to ensure 
that the current location of each mobile terminal is periodi- 
cally communicated to a network centre. As a result a 
dynamically updated map of the location of all of the mobile 

60 terminals can be maintained which can be further used to 
determine routing of messages. Similar systems are known, 
for example, in relation to cellular telephone networks and 
systems. A suitable system is disclosed, for example, in U.S. 
Pat. No. 5,612,703 which relates to a cellular communica- 

65 tion system in which the position of a selected user unit can 
be determined by issuing a timing signal from a node, 
analysing a timing response signal from the user unit and 
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determining the position of the user unit based on the round 
trip transmission and receipt time. 

U.S. patent application Ser. No. 08/614,068 commonly 
assigned herewith and incorporated herein by reference 
relates to a portable terminal including a data input and data 
display and a motion detector. When movement is detected 
a controller activates relevant circuitry. For example where 
the terminal is sensed to be in a first positional orientation a 
first function can be performed whereas when it is sensed to 
be in a second positional orientation a second function is 
performed. It will be seen that this capability can be incor- 
porated in the terminals of the present invention. For 
example it can be used to activate the terminal and deacti- 
vate it when it is removed and reinserted into the cradle. 

Yet another preferred variant of the invention is shown in 
FIG. 10. In this case the terminal 10 is an ultra thin client 
relying on the cradle for the majority of the computing and 
processing burden. In fact the terminal 10 can be represented 
by two basic components, a notepad facility 140 and a 
wireless communications component 142. The exact details 
of these components are not shown in detail as they will be 
well known to the skilled man. Effectively the notepad 
facility allows the input of data to the terminal and display 
of relevant information at the terminal. The processing 
burden at the terminal is largely restricted to this basic 
input/output capability together with control of the wireless 
communications component 142. The wireless communica- 
tions component communicates with a corresponding com- 
ponent 144 in the cradle 12. As a result raw data input to the 
terminal 10 is transmitted straight to the cradle 12 without 
the need for processing (other than for communications 
reasons) in the terminal, leading to a concomitant reduction 
in the processing and memory capabilities and thus power 
consumption of the terminal 10. Instead the bulk of the 
computing capability is held at the cradle, including a data 
processor 146 incorporating memory space as appropriate, 
additional memory space in the form of for example disks, 
a printer peripheral 150, and ethernet communications capa- 
bilities 152 allowing the cradle to form part of a larger 
wireless network connected, for example, to a host itself part 
of an Intranet or having access to the Internet. In effect, 
therefore, the portable terminal 10 is no more than a display 
for a computer held in the cradle, communications being 
carried out via the wireless communications link using for 
example RF or infrared protocols or any other suitable link. 
Rather than communicating directly with the cradle the 
terminal can communicate with one or more nearest access 
points, each themselves communicating with the cradle, 
allowing a greater range for the terminal. 

Such a system is particularly useful, for example, for 
dealers at a stock exchange or comparable implementations. 
The dealers can carry out their transactions using the hand- 
held displays, for example buying/selling stocks, keeping up 
to date with their current holdings and all other suitable 
transactions without the need for major processing, memory 
or power requirements in the terminal. When the terminal is 
not required it can be returned to the cradle for downloading 
of any further information that is required, for updating of its 
internal applications by the cradle and for battery recharg- 
ing. As a result a useful, lightweight and highly mobile 
terminal is provided with the background applications 
expected from a full scale personal computer or equivalent. 

Yet further implementations envisaged for the terminal 
include the provision of an AM/FM radio and/or broadcast 
television receiver incorporated into the terminal. As a result 
the user may use the unit for entertainment as well as 
computer-related tasks. Such a terminal is shown in FIG. 11. 
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The terminal includes a display 154 which is adapted not 
only for presentation of text and icons, but also video 
images. The terminal then further incorporates a keyboard, 
for example a full alphanumeric keyboard 156 allowing 

5 operation of the terminal either as a personal digital assistant 
or, in conjunction with a wireless link, as a low level 
personal computer. The terminal 10 further includes addi- 
tional controls 158 allowing the selection and/or control of 
a TV. or radio facility — for example volume/brightness/ 

1Q channel and so forth. As a result a portable computer is 
provided which makes additional use of its display functions 
by allowing a T.V. receiver to be incorporated, as well as 
optionally a radio facility. 

In an alternative configuration which can be used as an 
enhancement or adaptation of the above embodiments, or as 

15 a stand-alone product, the portable terminal can comprise an 
Internet "browser". This allows operation in conjunction 
with the "ultra thin" client facility. In effect, the client, apart 
from basic processing displaying communication facilities, 
carries browser software allowing the user, via the wireless 

20 link to the cradle, to browse the Internet for relevant 
applications and information. Using this basic facility, appli- 
cations and/or data can be called up on demand and stored 
in a lower level short term memory for as long as they are 
required. As dedicated software and applications are not 

25 required on the terminal itself the storage and processing 
requirements are correspondingly reduced. An icon-based 
display can be incorporated on the terminal allowing user- 
friendly access to the Internet or Internet access as one of 
various possible options on a selection menu. Such a system 

30 can, for example, be implemented using as a basis the 
computer language Java (a trade mark) and supporting 
software available from Sun Microsystems (a trade mark). 

These points are of particular relevance now that Internet 
Web "pagers" have moved on from being static entities 

35 viewable using a browser to true applications or "applets". 
Systems have been developed on existing local networks in 
which browser capability is introduced to existing hardware, 
forming a "web top". In many applications this comprises 
the first step to a move towards a true "thin client" — it is 

40 envisaged that conventional "fat clients" are generally truly 
required only for dedicated use high volume processing 
applications. Introduction of such browsers allows the user 
to access the Internet via the Intranet for downloading of 
applications and information together with corresponding 

45 broadcasting of information. In addition to browsing ser- 
vices the system can support mail services, administration 
services and so forth as is well known. 

As discussed to a certain extent elsewhere, the advantages 
of this system include security, update at run time and 

50 virus/tampering monitoring. Applications are developed 
more quickly because of the level of use to which they are 
subjected and hence testing. Because applications are stored 
at the server, administration can be centralised and users can 
obtain the most recent update consistently across the system. 

55 The system can support multimedia applications largely 
irrespective of the client platform — for example a telephone- 
type system including a display, personal digital assistants, 
set-top boxes, point of sale devices/kiosks, entertainment 
facilities and so forth. 

60 Systems incorporating the terminal/cradle facility dis- 
cussed above are of benefit, for example in mobile opera- 
tions such as packaging, tracking systems and courier sys- 
tems. Such a system is shown schematically in FIG. 12. The 
user 160 carries a portable terminal 10, preferably having 

65 laser scanning and pen-based data capabilities as discussed 
above. The terminal is rechargeable at a cradle 12 mounted 
in the user's vehicle 162 and can also download information. 
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In the embodiment shown the cradle is installed on the 
dashboard although it can also be installed on the seat or 
floor. The cradle 12 is connected to the vehicle battery 164 
or if required an auxiliary power supply. This connection 
provides the basic power from the vehicle to the terminal for 5 
battery charging and communications functions. Battery 
charging begins automatically when the terminal is inserted 
into the cradle. The cradle preferably carries a display 
indicating when the battery is being charged, and when the 
battery is fully charged, and a cut-off facility is included 
such that power is no longer drawn from the vehicle once the 
battery is fully charged. The terminal can of course use 
modular battery packs allowing a first battery pack to be in 
use while a second battery pack is being charged. 

The cradle incorporates or cooperates with a vehicle 
mounted wireless wide area network modem allowing trans- 35 
mission to and from an access point 166, itself communi- 
cating with a host 168. As a result, via the host, two-way 
wireless data transmission is achieved between remote 
operation sensors and mobile field personnel. For example, 
pick up and delivery times, work orders, activity reports, 20 
transaction records and all other relevant information can be 
communicated between the user 160 and the host 168 
quickly and efficiently. In particular the user 160 can input 
information to the terminal 10 via the keyboard or via a 
scanner or pen reader or other suitable input interface, and 25 
await downloading information each time the terminal 10 is 
placed in the cradle 12. Alternatively the terminal 10 can 
communicate via a wireless link with the cradle 12 for 
instantaneous data transmission at an appropriate level. 

Preferably the system incorporates an automatic "return 30 
receipt requested" facility, where the terminal 10 is an 
Intranet server terminal. A server terminal of this type is 
described in more detail in co-pending U.S. application Ser. 
No. 08/827,263 filed Mar. 28, 1997 commonly assigned 
herewith, which is incorporated herein by reference. In 35 
essence the server terminal includes the server software 
within the terminal itself allowing direct creation of Internet 
files/"websites" without the need for complex communica- 
tions with a remote server. In such an implementation, the 
cradle 12 is provided in the vehicle 162 as shown in FIG. 12 40 
and the user 160 takes the terminal 10 to the package 
recipient to sign for the package, noting the time of delivery. 
As the terminal/cradle is a server (in an alternative imple- 
mentation the server software can be incorporated in the 
cradle with no loss in efficiency and a reduction in the 45 
processing burden on the terminal), and the server can 
communicate over a wide area network to the host or depot, 
an interface can be provided to the Internet allowing the 
sender of the package to determine at any time if the package 
has been delivered yet, or whether a delivery has been 50 
attempted but the package has not been received. 
Accordingly, the delivery company can set up an additional 
facility to attract and satisfy customers, giving instantaneous 
information, via the Internet, on the status of any delivery. 

The detailed implementation of this can be carried out in 55 
various ways. For example the sender of the package can 
access the delivery company's website and then trace the 
progress of the particular package of interest using, for 
example, a code number assigned at the time of ordering the 
delivery. At the same time the progress of the package can eo 
be logged by the user, or delivery agent by entering the 
delivery or attempted delivery times against the code. The 
code can, for example, be read by a scanner provided in the 
terminal from the barcode provided on the package, if 
appropriate. 65 

Logging of the progress of the package can be improved 
yet further by logging transfer of the package at intermediate 
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stages between the sender and recipient, for example, at each 
stage of the depot chain. The development of a routing table 
is of particular importance in the general case where the 
exact route to be taken by the package via the depot chain 
is not decided at the time that delivery is ordered. This can 
facilitate double checking of the progress of the package. It 
is preferred that the routing table features details of the 
ultimate delivery truck as this will be easier to trace than 
individual packages. Preferably the sender pays a premium 
for this system of "instantaneous return receipt" so that the 
burden of transmitting the status of every package is reduced 
and need not be accessible on a real time basis except where 
paid for. 

Referring to FIGS. 13a and 136 a particularly useful 
implementation of a portable terminal is shown for use with 
the delivery implementation discussed above. In such imple- 
mentations it is desirable for the user to have both hands free 
for delivery of packages. Accordingly a "pendant" type 
scanner 170 is used, hanging around the user's neck. The 
terminal includes a scanner window 172 angled so as to 
point in the direction of a package held at waist height by the 
user. Such a package is shown as 174. The terminal 172 is 
thus able to scan the package and any barcodes held on it 
with optimum ease. For simplified manipulation the terminal 
further includes controls 176 and a display 178 on an 
upwardly facing surface such that the user can manipulate 
the controls and read the display without having to remove 
the pendant scanner. The terminal 170 can in addition 
communicate with, or interface with, the cradle 12 in the 
manner discussed above. 

As discussed above any uses can be envisaged for the 
terminals of the type discussed above, including warehous- 
ing and generally logistics-type arrangements. The "thin 
client" system as described above is particularly suitable for 
incorporation with existing infrastructures including the 
hardware — PC's systems, networks and data tools, and 
software — databases and so forth which are already in place. 
This applies throughout the relevant areas of the market for 
example retail, distribution or manufacturing. Such a system 
will preferably incorporate a central server carrying a suit- 
able database together with appropriate clients — for 
example wireless terminals of the type described above 
incorporating a graphical user interface to the user. The 
system introduces the benefits of real time operation which 
shortens the lead time on instructions and provides optimum 
implementation of both staff and hardware, at the same time 
allowing checking to take place on an immediate, continuing 
basis. Inventory information can be dated and processed in 
real time. Levels can be tailored accordingly and optimized/ 
minimized. The user will automatically know where items 
are stored and be able to locate them promptly. At the same 
time the administrative burden is decreased. All of this is 
achieved without costly across the board changes to the 
existing hardware infrastructure. 

The use of an icon based user terminal means that the 
system can be introduced quickly and with simple training 
only, but the system can also be extended to more complex 
systems including wave planning, resource scheduling, pro- 
ductivity measurement and real time assessment and order- 
ing of jobs. As the inventory is continually updated there is 
no down time for physical inventorying. Management, data, 
inventory, stock and other relevant reports can be obtained 
at any time again decreasing the administrative burden. 

A central server can run both client-types instantaneously. 
In addition to wireless terminals run via some form of radio 
network controller, PC's or other fixed terminals can also be 
wired to the system either at the base station or remote. 
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Standard interfacing communications protocols can be There will be a single 1Mx16 DRAM 404 on the unit, 

incorporated together with standard network architectures to providing 2 MB of DRAM. This will be capable of low 

achieve a reliable, interchangeable and adaptable system power and self refresh. 

preferably linked into other business systems as required. ^ scanner mterface ^ ^ be> for examplej the 

Terminal/cradle arrangements of the type discussed above 5 pre-programmed 8052 used on the currently available 

provide compact base stations allowing high speed data S£1222 decoder board ^ e decoder board itself will not 5e 

networking at the same time as battery charging for the used • the ^po^ from it . m 486 will communi- 

terminals. The systems are appropriate tor transportation . ... ♦ j • i ^ A a+<\ c 

j t . J £ r v.. ui- C . cate with it via its integrated serial port. A scanner 412. for 

and logistics companies, warehouse facilities, public safety, . . pri . nn . . * j 

retail and other appropriate organisations. Preferably upon exam P le the SEl200 ' 15 also ""»nx>rated. 

initiation, the cradle powers on and performs self -diagnosis The interface to the radio 414 will be preferably a simple 

to ensure proper system operation. Battery charging prefer- 8 bit parallel port, although a PCMCIA can be used. The 

ably begins automatically when the terminal is seated in the radio module will be a pure radio capability only or "dumb 

cradle and indicators such as LED's can be provided on the "kappa"" unit that does not have its own CPU, flash, RAM, 

cradle to indicate when power is on and when charging is etc. 

taking place. Data transmission can be quickly and effi- 15 j^ CTer are two options for LCD support. The 486SXF 
ciently achieved with a host for example by modem using processor 400 supports up to 320x200 display. Use of the 
standard communications protocols. Master cradles can be 486SXF allows a "dumb" LCD unit without built-in con- 
linked to, for example, a host PC or another cradle chain. troller. If the SXL version is used, the LCD controller must 
Preferably standard interfaces such as RS232 and RS485 are have its own controller. 

provided for use with a variety of portable printers and 20 ^ keyboard 4U js just ^ swi(ches Debouncing is 

peripherals. done by ^ ^ processor 400 

The system can also be mounted in a vehicle where ^ emire ^ off a si , e 5 voh { ^ radio 

appropriate for transportation and courier companies, 4M ^ ^ ^ n does ^ m m This 

utilities, public safety organisations field sales and service 2$ costs ^ ^ eliminates ^ Qeed for , te 3 3 

and other appropriate operations The cradle includes the y { ^ reduci ^ ^ 

capability for m-vehicle battery charging in two-way wire- ™ . , • 

less communication. It can be installed for example on the ^ P"* 00 *! ™ de \* a T, A ^ 

dashboard, seat or floor of the vehicle and can take power motherboard and the Kappa radio module. ^On one side of 

from the vehicle battery. The system can allow two-way , n the motherboard are the keys 416, LCD 402, and whatever 

wireless data transmission between remote operation centres 30 P^f « n * ^mbled thereon. On the other side is the radio 

and mobile field personnel, allowing rapid transmission of ™dule *14 (attached directly to the motherboard) and the 

pick-ups and deliveries, work orders, activity reports and re ?' of th « P"?- 1 Tbe ^ ole th,n 8 be , % ,0 A hlgh '.~?5 

transaction records. wlde ' an 4-6 long- " e scanner 402 also mounts on it. The 

. ... ..' .„ , . . . „ goal is to eliminate all the flex cables, further reducing costs. 

In either case it will be seen that the provision 01 an 0 . . f 

ultra-thin client reduces the weight and power requirements ^ software on the desi S n shown ln nG - 28 15 budt 

of the hand-held terminal making it yet more suitable for the around , a smaU ' non-preemptive multitasking kernel that 

portable uses envisaged. currently runs on known radio cards such as the Spectrum 24 

Many of the components forming the detailed embodi- cx t ^VT^^Z ^Pf' ^ 

ments discussed above, are individually known to the skilled „ <=ard) There are tasks for handling the user interface, Crux 

person and do not require detailed discussion here. or Ce,us . 41 *> xn(h ^ and rec °! vm S' and roamin 8- ^ 

¥ .„ , , • communicate via shared variables and message passing. 

It will be seen that it is highly desirable to create clients ^ ^ an ^ ^ ^ is ^ bwest dori task and u m * 

hat are "web enabled , that is, configured for connectivity be ted TOs task fonns the b ^ fo / a ^ Ued 

to the Internet. In many cases it is desirable to remove ^ ^ ^ ^ ^ ^ J* 

previous operating system based terminals using, for 45 ^^^g exists 

example, DOS and move instead to, for example, HTML T . . , ' . , , lt 

(hypertext mark-up language). Referring to FIG. 28 the , ^ model there is one task that operates at task level, 

hardware and software design for a web optimised terminal U P erforms f . Kn " of , ,ests which mav re * ult ""J™ 

is shown. The hardware model presents the major sub- Processing taking place. Interrupts «e generally enabled at 

systems. The software model describes how the radio and so aU times - ^ s,ructure 15 shown m 29 - . 

HTML software coexist. ^ should be noted that the tasks may be quite complex. 

Hie digital portion of the design is fairly simple. The For exam P le the test ma y be whether a P acket has been 

primary CPU 400 can be, for example, a National 486 SXF received on the RF interface. If one has been, the packet is 

or SXL (Trade Mark). It is a highly integrated CPU that P assed t0 a network P rotoco1 stack that Processes it. 

includes a variety of peripherals including LCD 402 55 This software model has been used successfully on known 

controller, DRAM 404 controller, timers, serial ports, etc. It systems for pagers and modems, for example the Symbol 

also has an onchip code cache and extensive facilities for Technologies Spectrum 24 pager and Modem. Accordingly 

low power operation. It executes 32 bit protected mode 386 further detail is not required here. The pager version 

instructions however it cannot run DOS or Windows (Trade includes the radio firmware, UDP/IP protocol stack, pager 

M ar ks) t 60 protocol interpreter, and pager user interface all running on 

There is a single 128 KB flash memory chip 406 con- a sin S le 80188 CPU - the HTML runtime code has been 

taining compressed object code. When the unit starts up the designed to fit into this single task, polling model, 

code is decompressed into the DRAM 404 and executed Known cradles have various basic requirements: 

from there. The 128 KB should contain about 256 KB of 86 Full hardware signal compatibility at the connect between 

object code. This code contains the radio firmware, setup 65 the cradle and the host such that the host does not 

routines, and sufficient Web Client code to download the require modification, and full hardware signal compat- 

actual runtime code from a server. ibility with a serial port present on the terminal. 
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Low insertion force connection between the terminal and 
cradle allowing frequent and preferably unlimited 
removal and re-insertion. 

Full hardware register compatibility within the terminal 
with existing communication software, for example 
IBM PC compatible communications software.* 

Support for "chaining" of multiple cradles to a single host 
serial port. In one embodiment a "master" cradle is 
provided for connection to the host, and supports a 
large number of "slave" cradles. Two access modes 
must be supported, single access mode and multiple 
access mode. In single access mode, one terminal at a 
time receives exclusive control and the host serial port 
and all of the terminals experience results equivalent to 
"no cable attached". In multiple access mode, all ter- 
minals are granted receive access to the host serial port 
but the right to transmit is granted to only one terminal 
at a time. Both modes should support standard appli- 
cation software without modification despite the occur- 
rence of multiplexing. 

The terminal/cradle should be implementable in a vehicle 
configuration as discussed above. 

It is proposed to use IrDA (Infrared Data Association) 
compatible optics for the zero insertion force interface 
to allow use of the terminal with readily available 
(non-dedicated) IrDA compliant peripherals and host 
computers. 

Solutions to the various points are discussed below. 
Solution 1 

Each terminal comprises two pairs of optics (two trans- 
mitters and two receivers) as does each cradle. Accordingly 
two full duplex datapaths are provided. Each cradle contains 
a microprocessor plus two pairs of optics per slot (for 
receiving a terminal). In this four slots design, a single 
microprocessor handles all four slots. The primary optical 
channel between the cradle and a terminal carries the data 
part of a full IBM-PC compatible 9 wire series interface, for 
example TXD, RXD and SG. The auxiliary optical channel 
between the cradle and a terminal carries control informa- 
tion (DTR and RTS), status information, (DSR, DCD, CTS, 
RI) of a full IBM PC compatible 9 wire serial interface and 
bus information (BREQ and BACK). 

The data interface is gated between the optics and the 
RS-232 by the cradle. The control and status information is 
communicated over the auxiliary optical channel. Within the 
terminal itself, control, status, and bus information are used 
to produce the effects of single or multiple access mode as 
required. 

Multiple 4 slot cradles could be chained together (up to 4 
physical cradles, for 16 slots). The bus signals (BREQ and 
BACK) are passed as "tokens" from one cradle to the next 
to provide inter-cradle multiplexing. 

The BIOS of the hand-held computer implements the 
cradle protocol and provides both IBM PC-compatible serial 
BIOS services and a proprietary extended serial BIOS 
service set. Since few, if any, IBM PC-compatible serial 
communications program use either set of BIOS services 
(instead of going directly to the hardware), communications 
via the cradle cannot support standard communications 
applications. Since this is also true of the physical serial port 
this is not a particular hardship. A single slot version of these 
cradles has all the same functionality of the 4 slot versions 
except it does not support chaining. Since only one slot is 
present and the chaining logic is not required, the hardware 
design is somewhat simpler. The two optical channels are 
handled identically, however, and the terminal BIOS code is 
the same. 
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An alternative single slot configuration is simplified and 
does not include chainability or an optical interface. A 
modular (phone jack) style of connector can be used to 
provide either cabled serial communications (via an adapter 

5 cable) or can be used as the cradle "docking" connector, 
which provides a wired path for both of the data channels 
that are normally optical. 

To improve IBM PC-compatibility an alternative 
approach can be used to emulate the IBM PC serial com- 

1Q munications interface. This involves "bridging" the control 
and status information (conditioned as appropriate based on 
bus information) between the auxiliary optical channel and 
the "emulated" UART registers. This bridging is done using 
a special "Super-State" mode of the Chips and Technologies 
F8680 microprocessor in the terminal. Since all software in 

15 this device runs in real-mode, most "well-behaved" IBM 
PC-compatible serial communications programs could be 
used. 

One solution to reduce the cost of multiple cradle instal- 
lations is eliminating the microprocessor in all but one (the 
20 "master") of the cradles in each "chain" of up to for example 
60 cradles. 

In order to meet all of the common requirements for 
cradles (especially chaining), a method for synchronising 
access to the cradle bus from multiple hand-held computers, 

25 without a processor in each cradle, is required. The mecha- 
nism can be a variant of CSMA/CD (Carrier Sense Multiple 
Access/Collision Detection). In this matter, the processors in 
the hand-held computer themselves, with the co-operation of 
the single processor in the "master" cradle, manage all 

30 required bus control. 

Unlike the above variants a single data channel is used, 
thus freeing up a UART on the terminal and reducing the 
number of optic pairs in a terminal+cradle combination from 
4 pairs to 3 pairs (2 transmitters and a receiver in the cradle 

35 and 1 transmitter and a receiver in the terminal). The third 
pair (a transmitter in the cradle and a receiver in the 
terminal) is required to allow the Carrier Sense and Collision 
Detection. 

To allow for interchaining with different cradles, a switch 
40 on the "master" cradle is used to select which type of 
emulation to support. This feature allows a chain of cradles 
to be placed at the end (farthest from the host) of a different 
free cradle chain. 
To provide IBM PC-compatibility, an approach similar to 
45 that discussed above is used to emulate the IBM PC serial 
communications interface. Since no direct data channel is 
available (since there is only a single data channel), data, 
control, and status information must travel on the same 
channel. This requires that the "emulation" be more com- 
50 plete. 

The emulation is done using support hardware in the 
terminal ASIC interface and control. This involves using I/O 
register traps to generate NMI (non-maskable interrupts) to 
allow the cradle support software to emulate the results of 

55 application accesses to the UART registers. Using an open 
system based on the 486 processor, intended to run protected 
mode software such as DOS extenders and Windows (trade 
mark), the potential number of interactions with the cradle 
support software is effectively infinite. 

60 In a further cradle approach a modular (phone jack) style 
of connector is used to attach a serial adapter cable to attach 
to the cradle. The cradle, however, simply passes the signals 
through to the cradle serial port connector. Since the serial 
port is IBM PC-compatible, the cradle is as well. 

65 Where the device and its cradles do not support internal 
battery charging, the cradle is effectively reduced to a "port 
replicator" or "cable extended" and a stand. 
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As a further development is it proposed to make full use 
of IrDA capability, in particular using IrDA for wireless 
communication and using the same IrDA optics as the cradle 
interface to avoid to unnecessary duplication of hardware. 

Using IrDA 9 wire emulation mode (called IrCOMM) to 
the standard protocol stacks designed for this type of appli- 
cation allows the cradle to be an IrDA+IrCOMM to RS-232 
converter with multiplexing. The multiplexing could be 
relatively simple (i.e. the "token" passing scheme discussed 
above), hence it can be implemented in hardware as an 
ASIC. Alternately, the multiplexing could be performed by 
the processor needed to run the IrDA protocol stack and 
IrCOMM layer. 

Adding a processor to each cradle may still be more 
efficient than putting different sets of optics on each hand- 
held computer. Since the IrDA optics are half duplex, they 
cannot easily be used in central constant cradle schemes. 
Use of the IrDA+IrCOMM standard protocol stack layers is 
the logical method of using these optics. In the cradle, since 
these protocol layers must be converted into RS-232, a 
processor is mandatory. 

Within the terminal, emulation of an IBM PC-compatible 
serial port is still required. An approach similar to that 
discussed above could be used to "wrap" the IrDA and 
IrCOMM interfaces and make them look like a standard 
COM port. Alternately, to avoid the software interactions 
that the emulation approach experienced, it is possible to add 
another microprocessor (such as an 8031) to the hand-held 
computer itself. This processor would then emulate the 
"hardware" interface of the UART and run the IrDA+ 
IrCOMM layers. This approach would eliminate any pos- 
sible software incompatibilities. 

It is further desired to develop a subsystem for use in a 
terminal that complies both with external standard such as 
IrDA and any dedicated internally determined standards. 
The subsystem must be capable of communicating with 
other internal standard or IrDA equipped computing devices, 
with internal standard and/or IrDA, and must be suitable for 
use in the implementation of non-physical connection 
cradles. These cradles must be capable of providing emu- 
lation of a full RS 232 serial port (with and without cradle 
chain). A suitable system covers the functionality of the 
subsystem, the hardware and software needed to implement 
the subsystem (both at terminal and cradle portions) and the 
design, implementation, interface and the characteristics of 
the subsystem and identifies the functional hardware and 
software requirements for the complete internal standard/ 
IrDA subsystem (both the terminal and cradle portions). 

Referring to FIGS. 14 to 21 the wireless communications 
strategy for the system is based on two fundamental physical 
communications technologies: IrDA (Infra-red Data 
Association) and a dedicated proprietary internal standard 
arranged to eliminate peripheral cables. IrDA is open sys- 
tems standard. For both the same communications protocols 
(IrLAP, IrLMP, TinyTP and IrCOMM) will be used to allow 
transparent inter-operation amongst the two interfaces in a 
system equipped with both. 

Both technologies can be used in any or all of the 
following three operational modes: Point-to-multipoint "Air 
Network" mode, Point-to-point "Serial Port Emulation" 
mode, and multi-point to point "Chainable Cradle" mode. 
The system provides for one or more of the following 
configurations as shown in Table 1: 
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TABLE 1 



5 



Configuration Name 


Technology Used 


Mode Used 


Vehicle Cradle 


Internal Standard 


Serial Port 




and/or IrDA 


Emulation 


Depot Cradle 


Internal Standard 


Chainable Cradle 


IrDA Peripheral 


IrDA 


Air Network 



10 Supporting the combination technologies provides optimal 
connectivity and flexibility. IrDA provides fairly high band- 
width (115.2 K Baud), line-of-sight, short range (sub-meter), 
low power communications, plus compatibility with 
industry-standard IrDA peripherals. The internal standard 

15 provides a lower bandwidth (19.2 K Baud), omni- 
directional, medium range (3-6 meters), higher power com- 
munications. By providing a single integrated solution that 
supports the two technologies and allows them to be used 
interchangeably, the system should maximize the potential 

20 for wireless connectivity. 

FIG. 14 shows an IrDA "air" network allowing IrDA 
wireless communication between a terminal 180 and each of 
an IrDA equipped server 182 and an IrDA compatible printer 
184, IrDA communication between IrDA equipped lap-top 

25 or other portable computer 186 and each of the server 182 
and printer 184, as well as IrDA communication between the 
terminal 180 and the lap-top 186. In FIG. 15 serial port 
emulation is shown for IrDA and/or internal standard tech- 
nology. A terminal 180 communicates with a cradle 188 by 

30 IrLAP, IrLMP, TinyTP and IrCOMM and either of IrDA or 
the internal standard technology. Where IrDA technology is 
used the cradle 188 communicates with a host/server gate 
way 190 via a RS-232 C interface. Where the system uses 
the internal standard technology the cradle 188 communi- 

35 cates with a printer 192 via a RS 232C interface. 

The IrDA and/or internal standard technology chained 
cradle shown in FIG. 16 includes communication between a 
plurality of terminals 180 and respective cradles 188 com- 
municating by either of IrDA or internal standard technolo- 

40 gies together with IrLAP, IrLMP, TinyTP and IrCOMM. The 
cradles communicate with each other via a cradle bus and a 
master cradle communicates with a host/server 190 via an 
RS 232C interface. 
In the in-terminal hardware design with IrDA and internal 

45 standard shown in FIG. 17 a CPU 194 communicates with 
a multiplexer 196 directly and via a UART 198. The 
multiplexer 196 communicates via IrDA drivers 200 with 
the IrDA optics 202 and via an internal standard specific unit 
204 with an antenna 206. The terminal as a whole is 

50 designated 208. 

Referring to FIG. 18, a cradle 210 incorporates the serial 
port emulation hardware design with IrDA and the internal 
standard cooperates with a microprocessor 212 having RAM 
memory storage 214 and ROM memory storage 216 at its 

55 core. The microprocessor 212 communicates to the host 
(shown schematically at 218) via a UART 220, an RS 232 
driver 222 and an RS 232 connector 224. The microproces- 
sor 212 communicates with a multiplexer 226 directly and 
via a UART 228. The multiplexer 226 communicates with 

60 IrDA optics 230 via IrDA drivers 232. The multiplexer also 
communicates with an antenna 234 via an internal standard 
unit 236. 

Referring now to FIG. 19 a chainable cradle design with 
IrDA and internal standard technologies comprises a micro- 
65 processor carrying RAM memory storage 240 and ROM 
memory storage 242. The microprocessor 238 communi- 
cates with an arbitration unit 244 directly and via a UART 
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246. The arbitration unit arbitrates between the communi- 
cation to the next cradle away from the host and commu- 
nication to the host or the next cradle towards the host. The 
arbitration unit 244 in either case communicates with a 
dedicated RS 232C connector 248a, 248fc via a dedicated RS 
232 driver 250a, 2506. The microprocessor also communi- 
cates with a multiplexer 252 directly or via a UART 254. 
The multiplexer allows communication with an antenna 256 
via an internal standard unit 258. The multiplexer 252 also 
communicates with IrD A optics 260 via an IrD A driver 262. 
The cradle is shown generally at 264. 

The software data/control flow within the terminal is 
shown schematically in FIG. 20. The IrD applications 264 
flow via TinyTP, IrLMP, IrLAP 266; Real UART 268 and the 
IrD A optics and drivers or internal standard units in antenna 
270. Legacy applications 272 flow via emulated UART 274; 
IrCOMM 276 and then follow the same path as the IrDA 
applications. 

FIG. 21 shows software data in control flow within the 
cradle. Flow from IrDA to RS 232 bridge 278— RS 232C 
connector 280 is via UART 282 and RS 232C drivers 284. 
Data flow IrDA to RS 232 bridge 278— IrDA drivers and 
optics/internal standard unit and antenna 286 is via 
IrCOMM 288; TinyTP, IrLMP, IrLAP 290 and UART 292. 

Many client devices are configured to receive an adapter 
card allowing them to perform network access. The com- 
ponents of such devices and adapter cards are well known to 
the skilled person and will not be described in detail here. 
One example of a network adapter is the system sold under 
the trade mark SPECTRUM 24 by the assignees of the 
present application. 

In known systems such as that shown in FIG. 25 it is often 
desirable for a Client Device to perform Network File 
Access using Network Files System Clients (NFS) via 
Network Protocol Stacks on Network Adapters, To accom- 
plish this, the Client Device 350 must generally utilize a 
PCMCIA slot to hold the Adapter Card 352. Additionally, 
various Software Components, such as a PCMCIA Card 
Driver 354, Protocol Stack 356, and Network File System 
Client 358, must all be present and executing on the Client 
Device. 

For small, low cost Client Devices, the secondary storage 
needed to hold these Software Components may be large 
compared to the total secondary storage capacity of the 
device. Additionally, the RAM required to execute these 
Software Components may be large compared to the total 
RAM capacity of the device. Finally, the processing power 
required to execute these Software Components may be 
large compared to the total processing power of the device. 

Since many of these Software Components may need to 
be Client Device-specific, configuration and deployment of 
Network File Access on various Client Devices may be 
difficult. Additionally, the secondary storage required to hold 
the required Software Components may require the use of a 
second PCMCIA slot, which may not be practical or desir- 
able depending on the capabilities of the Client Device. 
Finally, the configuration and maintenance of a network can 
be very difficult and time consuming. 

The client device and network adapter card interface via 
a PCMCIA interface 362. In the case of the existing Adapter 
Card 352, the software consists of an autonomous radio 
control program 360 with an interface 352 to the ODI or 
NDIS driver 355 in the Client Device. 

The invention as shown in FIGS. 26 and 27 incorporates 
the functionality of the Network Adapter Card 370 into a 
System which also includes Network Protocol Stack(s) 372 
and the NFS Client(s) 374. The entire System is then 
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packaged into a PCMCIA card that emulates a standard 
PCMCIA ATA card. This allows any Client Device 376 
which is capable of accessing a PCMCIA ATA card to 
transparently access files from a File Server. Since the only 

5 interface between the Client Device and the System is the 
ATA/IDE interface 378, the Client Device need have only an 
ATA/IDE driver 380 NOT a network adapter driver, Net- 
work Protocol Stack(s), and NFS Client(s). 

The File Access Card 370 consists of a Processor, RAM, 
Flash and a conventional radio 388 for example of the type 
sold number the trade mark SPECTRUM 24 by the assign- 
ees of the present invention. This is basically the same 
design as the existing Adapter Card. 

The fundamental difference in the proposed solution is the 
software running on Processor 382. The interface to the 

15 Client Device ODI or NDIS driver is replaced by a direct 
interface to an ODI driver 390, one or more Protocol Stacks 
372, and one or more NFS Clients 374, all within the File 
Access Card 370 itself. All of these Software Components 
then run on the Processor 382 in the File Access Card 370. 

20 The software necessary to emulate an IDE disk drive is 
present to provide the interface to the Client Device. 

The software further includes a Radio Control Program 
394 unchanged from standard Radio Control Programs 
except that instead of interfacing to an ODI driver in the 

25 Client System via the PCMCIA interface 378, it interfaces 
directly to the ODI driver 390 running in the same processor 
within the File Access Card 370. The Protocol Stack(s) 372 
and NFS Client(s) 374 load on top of the ODI driver 390 in 
a similar manner to the way they would on a Client Device. 

30 The ATA/IDE controller software 396 must emulate the 
ATA/IDE interface 378 and use the services of the NFS 
Client(s) 374 to access the files on the NFS server in 
response to Client requests via the ATA/IDE interface 378 to 
access the emulated disk. 

35 In order to support multiple Protocol Stacks 372 and NFS 
Clients 374, the File Access Card 370 must either have 
multiple Protocol Stacks and NFS Clients, with a mecha- 
nism to select which one to use, or must provide a means for 
loading the desired Protocol Stack and NFS Client. 

40 The File Access Card 370 further includes suitable Radio 
Hardware 395. 

The Conventional Adapter Card Drivers require certain 
parameters (such as Net ID) to be specified. A mechanism 
must be provided for specifying these parameters. 

45 Additionally, Protocol Stacks 372 and NFS Clients 374 
typically require setup parameters (such as IP address, log on 
name, password, etc.). A mechanism is provided to specify 
this information. 

Numerous solutions to the problems of loading/updating 

50 Protocol Stacks 372 and NFS Clients 374, and setting 
parameter information can be devised. Since the hardware 
implementation contains Flash Memory 386, this is the 
obvious place to store these varying types of data. One 
method is to use a portion of the Flash memory 386 to 

55 emulate a disk (in the same manner used by a normal ATA 
Flash Card). This disk contains the standard Protocol Stack 
372 and NFS Client Files 374, as well as the configuration 
files (NET,CFG, PCTCP.INI, etc.) used to configure the 
Protocol Stacks and NFS Clients. All of these files are 

60 located in the root directory or in subdirectories of the ATA 
drive, and all are physically stored in the Flash memory 386 
of the File Access Card 370. To reconfigure or reload the 
Protocol Stacks 372 and/or NFS Clients 374, the Client 
Device need only edit or copy files within the Flash memory 

65 via the ATA driver. 

In order to allow access to both the local Flash memory 
386 of the File Access Card 370 and the files on the File 
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Server using the same interface, the File Access Card ATA 
Controller 396 must merge the files from the File Server into 
the disk it is emulating. The simplest way to do this is to treat 
each File System mounted via the NFS Client 374 as a 
subdirectory in the emulated drive. By limiting the File 5 
System names to 8 characters, the name of the File System 
can also be the name of the subdirectory (off the root of the 
emulated ATA drive) that is used to access that File System. 

When accesses are made to the sectors containing the 
directory information for a File System, the ATA 396 con- 1Q 
troller must obtain the current directory information from 
the File System via the corresponding NFS Client 374, 
construct the directory sectors accordingly, and make them 
available to the Client Device (via the ATA interface 378). 
When accesses are made to the data sectors referenced by 
the directory sectors, the ATA Controller 396 must obtain the 15 
data for the accessed files via the NFS Client 374, create the 
data sectors, and make them available to the Client Device. 

If the File Access Card 370 has sufficient Flash memory 
386, it may make sense to cache sectors of directory or data 
so that frequent accesses by the Client Device execute faster. 20 
This must be balanced carefully to trade off quick access 
with accurate data. Since the files on the mounted File 
system may be accessible by other Clients, they are not 
guaranteed to remain valid once they have been cached in 
the File Access Card 370. Adjustments to allow the Client 25 
Device to control the behaviour of the caching logic would 
be necessary. This information can be stored in a configu- 
ration file along with the other parameterization information. 

Security issues may arise due to the need to store log on 
names, passwords, etc. within the Flash memory 386 of the 30 
File Access Card 370. As this information now travels with 
the card and, being portable, may represent a security 
breach, it is possible to use various encryption techniques to 
secure the configuration files from unauthorized browsing. 
The File Access Card 370 needs to make a temporary, 35 
unencrypted copy of this file for the use of the Protocol 
Stack(s) 372 and NFS Client(s) 374 whilst it is starling up. 
Once it is running, this temporary copy can be removed. So 
long as this temporary copy is not accessible to the Client 
Device it does not represent a security breach. 40 

Data integrity issues may arise due to the need to power 
cycle the File Access Card 370 when used in portable Client 
Devices. Additionally, any time the card is removed from the 
Client Device, it loses power. The design of the ATA 
controller 396 must ensure that a write is completed fully or 45 
not at all. This is a standard design constraint of Flash 
memory-based ATA controllers. The File Access Card 370 
must take this precaution one step further. A write cannot be 
considered complete until it has been successfully propa- 
gated to the File Server. Any local caching performed within 50 
the File Access Card 370 must synchronize with this all-or- 
nothing write behaviour. 

The File Access Card 370 must establish/reestablish con- 
nections and mount/remount File Systems automatically 
whenever power is applied to the card. This may take a 55 
significant length of time and access to the card may need to 
be delayed until this processing is complete. This is already 
possible with ATA cards, where the time needed to "spin up" 
a hard disk may be significant. The ATA/IDE 378 interface 
provides the mechanism necessary to delay access to the 60 
card until it is ready. Furthermore, when accesses to card 
data require NFS activity to get the data, individual accesses 
may be quite slow. The same mechanisms described previ- 
ously can be applied to hold off the Client Device until data 
is available. 65 

Since the File Access Card 370 must contain essentially 
the same hardware and firmware as a standard Adapter Card, 
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it could also be designed to operate as such an Adapter Card. 
This would, of course, require the Adapter Card Driver and 
Protocol Stacks to be present in the Client Device. This 
would allow the card to be used as either a File Access Card 
or a standard Adapter Card interchangeably (although not at 
the same time). 

It is also possible to create a custom communication layer 
between the Client Device and the File Access Card 370 that 
replaces the standard network layers that would normally be 
present on the Client Device. Since the File Access Card 370 
contains the ODI driver 390 and Protocol Stack(s) 372, there 
is no need to duplicate these components in the Client 
Device. The application interface to the network can be 
reimplemented to use this custom communication layer, 
instead of talking directly to the Protocol Stack(s) 372. The 
end result is that Client Device applications can utilize 
network services without actual Protocol Stacks 372 execut- 
ing on the Client Device. Suitable application interfaces will 
be well known to the skilled person and are not described 
further here. For example the interfaces available under the 
trade marks BERKELEY SOCKETS or WINSOCK would 
be appropriate. 

Using the above approach it is then possible to permit 
direct access to network services (e.g. via application 
interfaces) concurrently with access to File Server files. This 
would require, of course, that the File Access Card 370 
possessed sufficient computing capabilities to support emu- 
lation of the ATA/IDE interface 378 and support the custom 
communications layer at the same time. 

The above described arrangement gives rise to a number 
of advantages in applications. For example the invention 
provides support for wireless access to files on file servers 
from any Client Device such as a PCMCIA slot and supports 
access to ATA cards. Client Device specific protocol stacks 
or NFS Clients are not required. At the same time simplified 
configuration for access to NFS File System is allowed. 
Once a card has been configured for use with a given set of 
protocol stacks, NFS Clients and File systems it can be 
freely moved from Client Device to Client Device with no 
change in configuration required. Because no protocol 
stacks or NFS Clients need to be present on the Client 
Device reduced memory and secondary storage require- 
ments for Client Devices are achieved, allowing yet thinner 
clients. The protocol stacks and NFS Clients run in the File 
Access Card processor rather than in the Client Device 
providing consistent performance across multiple Client 
Devices. There is also potential reduction in the number of 
PCMCIA slots required to support a given application. Since 
all software components required to support file server 
access are present on the same card, many client devices 
may avoid the use of additional PCMCIA storage cards. This 
may allow Client Devices with only a single available slot 
to access file server files successfully. 

According to another aspect there is provided an embed- 
ded storage device for use in an embedded PC-based system 
allowing a single standard storage solution supporting 
directly executable storage (e.g. BIOS) and secondary stor- 
age (e.g. disk) with field upgrade ability, suitable for use in 
all PC-based embedded computing systems. Hereafter the 
embedded storage device is simply called the Device and the 
embedded PC-based computing system is simply called the 
System. 

One implementation of the invention is in relation to a 
"portable server", that is, a mobile terminal carrying server 
capability as described in more detail in copending U.S. 
application Ser. No. 08/827,263 filed Mar. 28, 1997 com- 
monly assigned herewith, which is incorporated herein by 
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reference. As shown in FIGS. 30a, 30b, 31a and 316, web 
server capability can be implemented in a plug-in card, for 
example a PCMCIA card. A mobile device 500 which can be 
any suitable mobile device such as a terminal of the type 
discussed above, personal digital assistant, digital camera 5 
and so forth including a card interface port 502, for example 
a PCMCIA or compact flash slot receives a card 504 at the 
interface. The card 504 carries server capabilities for 
example for the internet or worldwide web and the system 
thus acts as a transparent web server. Referring in more 10 
detail to FIG. 30b, the card 504 includes a PCMCIA or other 
suitable interface for communication with the mobile device 
500, flash memory 508 and an ATA (AT attachment) con- 
troller 510 used to implement the hard drive. The memory 
508 is for storing data produced by the mobile device and the 15 
card 504 further includes a CPU 512 which accesses the data 
and operates a web server software routine. The CPU 512 is 
configured to run a suitable radio communications module 
514, for example of the type available from the assignees 
under the trade mark "SPECTRUM 24 RADIO". CPU 512 20 
is also configured to handle the TCP/IP protocols. The 
mobile device 500 carrying the card 504 is thus able to 
communicate with a suitable nearby access point and then to 
a client PC via aerial or antenna 516. 

As a result the client PC can display a web page repre- 25 
sentative of data stored in the memory of the mobile device 
as desired. The card 504 can thus convert any device, as 
discussed above, into a server for the web. This is shown in 
more detail in FIGS. 31a and 31b. The mobile device 500 
collects data at a data collection point 518 which can be, for 30 
example, a still, video or digital camera, a bar code reader, 
a microphone or a data input point such as a keyboard. The 
data is stored, for example in the card 504 making use of the 
ATA controller 510. The card 504 cooperates with the device 
500 to act as a transparent web server and transmits the data 35 
from the card 504 via the antenna 516. The transmission is 
received by an antenna 520 to an access point 522 connected 
to the Ethernet backbone 524. Connected to the backbone 
524 is a client PC 526. Accordingly when, for example, a 
worldwide web browser of any suitable type is run on the 40 
client PC 526 and calls up the "web page" at the mobile 
device sending an HTTP request for the desired Universal 
Resource Locator (URL) the request is routed via the 
backbone 524 and acts as point 522 to the transparent web 
server formed by the device 500 and card 504. The data 45 
collected at the mobile device is transmitted back to the 
access point in response to the request and the web page is 
routed to the client PC 526. 

Turning to the physical requirements of the Device: 

The Device is implemented in one of two physical 50 
embodiments: Modular and Component. 

The Modular embodiment of the Device consists of a 
single, self-contained circuit board (or equivalent) which 
can be mounted on a circuit board (or equivalent) within the 
System. The subsystem implemented by the Component 55 
embodiment shall interface to the remainder of the system 
via the set of interface signals described below. 

Modular embodiments of the Device interface to the 
System via a standard connector of suitable type. This 
connector provides the set of interface signals described 60 
below. Additionally, this connector is low cost, low profile, 
and highly immune to shock and vibration. This connector 
is not intended to be used for frequent insertion and removal, 
since this aspect is concerned with embedded, non- 
removable applications. 65 

All embodiments of the Device interface to the System 
via the same set of interface signals. These signals represent 
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a subset of the ISA bus signals, the additional signal(s) 
required to interface to a standard BIOS EPROM, plus 
signals used to control Device options. The set of required 
signals is listed below: 
Power signals, for example 

+3.3 Vdc, 

+5 Vdc, 

+12 Vdc, 

Ground for various applications. 
Control signals, for example clock, data transfers, valid 
address, valid data, zero wait state for current bus cycle, 
oscillar clock signal, reset-return to default state and 
prepare for normal XIP and Disk operations. If 
necessary, the Device can drive this line to keep the 
system in reset state until its own reset is complete, I/O 
device read strobe command, I/O device write strobe 
command, memory read strobe command, memory 
write strobe command signal to the system that the 
current I/O or EPROM memory cycle must be 
extended. This signal must be used in accordance with 
the performance requirements described below, signal 
to the System that a 16 bit EPROM memory cycle is 
required. This signal must not be used by the Device 
unless the USEMEM 16 signal is present indicating 
that the System is capable of and willing to participate 
in 16 bit EPROM memory cycles. 
Indicate to the System that a 16 bit I/O cycle is 
required. This signal must not be used by the Device 
unless the USEI016 signal is present indicating that 
the System is capable of and willing to participate in 
16 bit I/O cycles. 
EPROM Control Signals for example: 

Indicate that the System is accessing the XIP section of 
the Device. This signal is generated by address 
decoding logic in the System and is presented after 
the appropriate address lines are valid. Indicate to the 
System that the XIP section access is complete and 
that the XIP section data is available on the data 
lines. If this does not occur within a single cycle, the 
Device must use the IOCHRDY signal to initiate 
extended wait cycles. 
Indicate to the System that the XIP section is ready for 
access by the System. This signal shall be activated 
after the initialization process instituted by the 
RESET signal is completed. The System shall not 
access the XIP section following RESET until this 
signal is activated by the Device. 
Indicate that the System grants permission to the 
Device to update the contents of the IPL subsection 
of the XIP section. When this signal is not present, 
the IPL subsection contents must not be modified 
(even if the appropriate commands are sent to the 
Device by the System). 
Device Option Control Signals including: 

Indicate that the system wishes the Device to enter its 
lowest power state as soon as possible. Power con- 
sumption and timing requirements are described 
below. Once in suspend state, the Device need not 
support XIP or Disk accesses until this signal is 
deactivated and the Device has resumed operation 
(indicated by deactivating the SUSPSTATE signal). 
Indicate to the System the current suspend state of the 
Device. If the Device is currently in suspend state, 
this signal will be active, otherwise it will be inac- 
tive. 

Indicate that the System grants permission to the 
Device to use full power at will. Full power opera- 
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tions performed at the discretion of the Device (e.g. 
background operations), are only allowed when this 
signal is active. Full power is always permitted to be 
used by the Device during an explicitly requested 
XIP update or Disk write operation, regardless of the 
state of this signal. Indicate to the System that the 
Device is currently using full power. This signal need 
only be set when the previous signal indicates that 
the Device is permitted to use full power in the 
background and when the Device is actually doing 
so. This signal may also, but is not required to, be 
used to signal use of full power during an explicitly 
requested XIP update or Disk write operation. 
Chip select signal for IDE to addressee. Drive Active/ 
Salve Present signal used by a Slave IDE device to 
acknowledge the Master IDE device during initial- 
ization. 

Signal used by the System or the external configuration 
fixture to indicate that the Device may be reconfig- 
ured and that the 5 and 12 volt supplies are available. 
The configuration of the Device shall not be changed 
(even if the appropriate commands are sent to the 
Device by the System) unless this signal is present. 

Indicate that the System is capable of executing 16 bit 
I/O cycles and is willing to interact with the Device 
using such cycles. The Device decides whether to 
use 8 and 16 bit cycles and indicates the choice to the 
System via the appropriate signal. 

Indicate that the System is capable of executing 16 bit 
EPROM memory cycles and is willing to interact 
with the Device using such cycles. The Device 
decides whether to use 8 and 16 bit cycles and 
indicates the choice to the System via the MEMCS16 
signal. 

Address Signals, for example 

To address the [up to 256 K of the] XIP section of the 

Device, the System. 
If an implementation of the Device chooses to expand 
the size of the XIP section beyond 256 KB, addi- 
tional address bits may be used to address the extra 40 
memory. The Device can assume that ALL address 
bits are valid when the appropriate signal is present. 
The design of a System using the Device must 
therefore ensure that the appropriate signal genera- 
tion takes into account the upper address bits. If a 45 
System were to generate that signal any time the 
lower address bits contained the right values, without 
regard to the upper address bits, then the Device 
might access memory other than the intended XIP 
section. 50 
Data Signals, for example 
When the appropriate signal indicates the need for an 8 
bit memory cycle, then only a first range is used. If 
the signals indicate the need for a 16 bit memory 
cycle, then the first range is used, but the latter range 55 
may only be used after signals indicates the readiness 
of the upper data lines. 
Interrupt Signals, for example 

IRQ signal supported by the Device. It is used only for 
IDE interface emulation. This signal may be con- 60 
nected to any available System IRQ line, but for 
compatibility, it is suggested that it be tied to the 
standard hard disk interrupt. 
All programming voltage(s) required to access the storage 
within the Device are generated within the Device from 
either a single 3.3 V or a single 5V supply voltage. A System 
need only provide one of these supply voltages, but may 
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optionally provide both. The Device must be capable of 
obtaining its normal operating power from either supply. 
These supply voltages are provided via the standard Device 
interface described above. 

The Device shall constrain its operation to conform to one 
of three power states as determined by the two Device option 
control signals discussed above. For example the signal may 
indicate that the Device should enter its lowest power mode 
and not respond to XIP or Disk section accesses or that the 
Device is free to use full power at its own discretion. 

In the absence of either signal, the Device shall support all 
access operations, but must perform higher power opera- 
tions (such as erase) only within the duration of an operation 
explicitly requested by the System (e.g. XIP update or disk 
write). 

If the Device supports background operation (moving 
blocks, erasing, etc.) it may only use frill power during 
background operations when the appropriate signal is 
present and must terminate such background operations if 
that signal is deactivated. 

The Device must be capable of changing states within 
milliseconds from the time the signal changes. The Device 
must report whether or not it is in suspend state via the 
appropriate signal. The Device must report any background 
use of full power via the appropriate signal. 

Table 2 describes the relationships between the power 
control and status signals and the power limitations for each 
state: 

TABLE 2 
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TABLE 2-continued 



Enter Current Device Maximum 

Lowest Suspend F\ill Power using Full Permitted 

State Power State State at Nil Power Current 

Name Signal Signal Signal Signal Load 

explicitly 1 ms) 

requested 

XIP update 

or Disk 

write 

operation 

is in 

progress. 



If the Device supports an IDE formatted section, then is 
shall support the standard Idle and Sleep commands of the 
ATA specification for controlling the power states of the IDE 
Disk controller. 

Since the Device is intended for embedded applications 
and especially mobile embedded applications, size is of 
significant concern. A system design incorporating the 
Device must balance capacity vs. available space. For 
example several discrete sizes will be standardized in each 
of the two embodiments (Modular and Component). 

The functional requirements of the Device are as follows: 

Referring to FIG. 22, a block diagram showing the logical 
structure of a typical implementation of the Device, the 
Device 300 provides support for two storage sections: An 
XIP (execute In Place) section 302 and a Disk section 304. 

The XIP section of the Device 304 supports adjustment in 
size ranging from OKB up to 256 KB in 64 KB increments. 

Larger XIP sections (greater than 256 KB) and/or smaller 
adjustment granularities (less than 64 KB) may optionally be 
supported, but must not prevent compatibility with the 
above requirements. 

The Device contains two logical controllers 306a, 3066 
and two logical storage areas 308a, 3086. Although specific 
implementations of the Device might combine the functions 
of the two controllers or storage areas, these terms are used 
herein to describe the required functionality. 

The XIP section 302 of the Device 300 is subdividable 
into 2 subsections: the IPL (Initial Program Loader) subsec- 
tion and the BIOS (Basic Input/Output System) subsection. 
For use in a specific System each Device is configured for 
the use of the required subsection(s). 

The IPL subsection of the XIP section of the Device, if 
configured for use by the System, is 64 KB in size and is 
addressed as the first 64 KB of the linear addressable area of 
the XIP section. If the design of a System requires the IPL 
subsection to be interchanged with the BIOS subsection, 
then the System must provide the logic to adjust the address 
lines supplied to the Device. No XIP section remapping 
logic is required to be implemented within the Device. 

IPL subsection sizes larger or smaller than 64 KB may 
optionally be supported, but must not prevent compatibility 
with the above requirements. 

The BIOS subsection of the XIP section of the Device, if 
configured for use by the System is adjustable in size 
ranging from 64 KB to 256 KB in increments of 64 KB. A 
BIOS size of 256 KB is allowed by a Device with a 256 KB 
XIP section only if the IPL subsection is not configured for 
use. If the design of a system requires remapping of areas of 
the BIOS, then the System must provide the logic to adjust 
the address lines supplied to the Device. No XIP section 
remapping logic is required to be implemented with the 
Device. 

Larger BIOS subsection sizes and/or smaller granularities 
may optionally be supported, but must not prevent compat- 
ibility with the above requirements. 
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For Modular embodiments of the Device, the partitioning 
of the Device into the XIP section and the Disk section is 
possible via a separate external configuration fixture to 
which the Device is connected via the standard connector 
5 described above. 

For Component embodiments of the Device the partition- 
ing of the Device into the XIP section and the Disk section 
is possible either in-circuit or via an external configuration 
fixture (if the System board itself is equipped with the 
1Q standard Device connector). 

The actual configuration of the XIP section of the Device 
is accomplished via the standard configuration interface 
described above. 

It is permissible to require 5V (for radio) or 12V supply 
voltages (in addition to the standard 3.3V or 5V operating 
15 voltages) for configuration purposes only. These supply 
voltages must not be used except when the appropriate 
signal is present. This signal identifies that the configuration 
supply voltages are valid and that Device configuration is 
permitted. At a minimum, the configuration supply voltages 
20 and the signal would be provided by the external configu- 
ration fixture via the standard Device connector. The con- 
figuration supply voltages and the signal are described 
above. 

The configuration of the Device, once performed, must be 

25 stored within the Device in a nonvolatile manner. This may 
require the use of a separate configuration storage area. 
Although it is possible to reconfigure the Device in the event 
of an erroneous configuration, this is considered an infre- 
quent event. It is therefore permissible to limit the number 

30 of reconfigurations (to allow use of a limited re-write 
configuration storage area). In any event, a minimum of for 
example 100 reconfigurations are supported. 

It is possible to detect the capabilities and configuration of 
the Device. The XIP section capabilities and configuration 

35 are determined via the interface described below. 

The Disk section of the Device conforms to one of two 
formats: IDE or FTL. A standard mechanism exists for 
determining which of the two formats is supported by an 
implementation of the Device. It is permissible to have an 

40 implementation of the Device that supports both formats. In 
such a case, an additional configuration option must be 
provided to select the format that will be used as the 
"primary" or "boot" device. The selection and detection of 
the disk section configuration is not required to permit read 

45 accesses to the XIP section interleaved with accesses to the 
I/O interface of the XIP controller. As a result, the System 
may not execute from the XIP section while updating or 
configuring the XIP section via the XIP controller. 

A Disk section supporting the IDE format provides a 

50 complete emulation of an IDE disk drive and is configurable 
to operate in any of the following modes: Primary IDE 
master, Primary IDE slave, Secondary IDE master, Second- 
ary IDE slave. The selection of the mode is determined by 
the settings of the appropriate signals described above. 

55 The management of the logical disk drive within the disk 
storage area is performed by the Disk controller within the 
Device. Access to the logical disk drive is via IDE com- 
mands sent to the Disk controller by the IDE driver within 
the BIOS. 

60 A Disk section supporting the IDE format is configurable 
to operate in either 8 or 16 bit wide modes. The data width 
is selected by the System, via the appropriate signal. 
Although this signal may be dynamically controlled by the 
System, it would normally be tied high or low depending on 

65 the capabilities of the System. When the signal is present, 
the corresponding signal is used by the Device to indicate to 
the System that 16-bit accesses are required. 
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A block diagram showing one possible implementation of lated linear memory. Since the Device is interfaced through 
the Device with an IDE format Disk section is shown in FIG. the ISA bus, the maximum speed of access may be limited 
23. where appropriate by the 8 MHz ISA bus speed. Use of ISA 

The Device implementation 310 shown contains separate bus extended wait states (through the use of the appropriate 

XIP312 and Disk 314 controllers and separate XIP316 and 5 signal) is permitted in the event of delayed access to XIP 
Disk 318 storage areas. The XIP controller 312 handles the data, but the maximum number of wait states shall be no 
configuration and updating of the XIP storage area and the more than 10 and the average number of wait states shall be 
Disk controller handles the emulation of the IDE drive using no more than 2. 

the Disk storage area. Although the System may optionally support the ability to 

A Disk section supporting FTL format is shown in FIG. 24 "Shadow" the BIOS or other system code from the XIP area 
in block diagram and provides a standard mechanism for into system RAM for improved performance, this must not 
accessing blocks for storage within the XIP storage area. be required to meet the performance requirements above. 
This standard mechanism must be the same regardless of the The programming requirements of the Device are as 
technology used to implement the disk storage area within follows. 

the Device and is described below. A special I/O interface is provided by the XIP controller 

The Device implementation shown contains a single 15 within the Device for determining the capabilities of the 
controller 320 serving as both the XIP and Disk (FTL) Device. This includes, but is not limited to, the following 
controllers and a single storage area 322 serving as both the information: 

XIP and Disk storage areas. No IDE support is provided, and Granularity of adjustment of XIP section (granule size) 

the XIP and Disk controller functions share common logic. Specified as an integral number of KB 

The BIOS of every System that utilizes the Device must 20 Maximum size of XIP section 
include both IDE and FTL drivers to ensure that all imple- Specified as an integral number of granules 

mentation of the Device may be used on all Systems, Must be greater than or equal to 256 KB 

The XIP section of the Device emulates 8-bit, byte- IDE format disk section presence flag 

addressable read-only linear memory (e.g. equivalent to a FTL format disk section presence flag 

similarly-sized EPROM). Address bits sufficient to address 25 size 0 f prL erase blocks (if FLT format is used) 
up to 256 KB are provided by the System to the Device and Specified as an integral number of granules 

they are decoded as necessary within the Device. The The Device is not required to permit read accesses to the XIP 
appropriate signal is provided by the System to the Device section interleaved with accessed to the I/o interface of the 
to identify that the XIP area is being addressed. Address XIP controller. Asa result, the System may not execute from 

decoding required to produce the signal from a wider range 30 the XIP section while updating or configuring the XIP 
of address bits is the responsibility of the System. section via the XIP controller. 

16-bit EPROM emulation may optionally be supported, A special interface is provided by the XIP controller 
but must not prevent compatibility with the above require- within the Device for determining the current configuration 
ments. If supported, the 16-bit EPROM emulation mode °£ ^ Device. This includes, but is not limited to, the 

shall be enabled by the System via the appropriate signal. 35 following information: 
Although the signal may be dynamically controlled by the Current I PL subsection size 
System, it would normally be tied high or low depending on Specified as an integral number of granules 

the capabilities of the System. When the signal is present and Current BIOS subsection size 

the Device supports 16-bit mode, then the corresponding Specified as an integral number of granules 

signal is used to indicate to the System that 16-bit accesses 40 Choice of IDE or FTL formatted drive as the "boot" 
are required. ™ ICe i« u 

The contents of the XIP section of the Device, if config- vfh™ 00111 are P resent 

ured for use by the System, are updatable, in circuit, via a ^ Device 15 not t0 P ermit read accesscs r to the f 

standardized programming interface. The Device supports ™ sectl0n interleaved with access to the I/O interface of 

the standard XIP section programming interface described 45 the ™ controller. As a result, the System may not execute 
below, regardless of the specific technologies used in the from the ™* sectl0n while u P datin g or configuring the XIP 
implementation the XIP storage area of the Device. sectl0n via the ™ controller. 

The IPL subsection of the XIP section of the Device, if A sp"** 1 1/0 mterface 15 P r0Vlded b V the ™ controller 
configured for use by the System is independently protect- ^ Device for selecting the desired configuration of 

able from update via a signal hat "protects" or "unprotects" 50 *e Device. This includes, but is not limited to, the following 
the IPL subsection. information: 

The Disk section shall be updatable, in circuit, via the Current IPL subsection size 

standard DOS disk driver and the standard BIOS IDE or Specified as an integral number of granules 

FTL drivers, regardless of the specific technologies used in Current BIOS subsection size 

the implementation of the Disk storage area of the Device. 55 Specified as an integral number of granules 

The rated storage capacity of the Device is defined to be Choice of IDE or FTL formatted drive as the "boot" 

the size of the Disk section supported by the Device when device 
an XIP section of 256 KB has been configured. This should When both are present 

provide a worst case measurement for all implementations. The Device is not required to permit read accesses to the 

Although it is permissible for an implementation to 60 XIP section interleaved with accessed to the I/O interface of 
extend the size of the XIP area beyond the requirements of the XIP controller. As a result, the System may not execute 
this specification, this extra space shall not be considered to from the XIP section while updating or configuring the XIP 
increase the rated storage capacity of the Device unless section via the XIP controller. 

incorporated into the Disk section when the XIP section is A special I/O interface is provided by the XIP controller 

configured to a size to 256 KB. 65 within the Device for updating the contents of the XIP 
The XIP section of the Device provides performance section. This includes, but is not limited to, the following 
sufficient to allow direct execution of code from the emu- functions: 
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Erase IP1 
Write IPL 
Erase BIOS 
Write BIOS 

The Device is not required to permit read accesses to the XIP 
section interleaved with accesses to the I/O interface of the 
XIP controller. As a result, the System may not execute from 
the XIP section while updating or configuring the XIP 
section via the XIP controller. 

When the Disk section supports the IDE format, then the 
standard IDE command set is supported. The System BIOS 
IDE driver is used to update the IDE format of the disk 
section. 

When the Disk section supports the FTL format, then a 
special interface is provided by the Disk controller within 
the Device for updating the contents of the Disk Section. 
This includes, but is not limited to, the following functions: 

Erase Block 

Map Block 

Write Block 

The Device permits read accesses to the XIP section inter- 
leaved with accesses to the I/O interface of the FTL con- 
troller. As a result, the BIOS FTL driver may execute from 
the XIP section while updating the Disk storage area via the 
FTL controller. 

Without further analysis, the foregoing will so fully reveal 
the gist of the present invention that others can readily adapt 
to various applications without omitting features that, of the 
standpoint of prior art, fairly constitute essential character- 
istics of the generic or specific aspects of the invention and, 
therefore, such adaptions should and are intended to be 
compounded within the meaning and range of equivalents of 
the following claims. 

What is claimed is: 

1. A mobile communications device, comprising: 

a) an activatable transceiver circuit for wireless commu- 
nication when activated with at least one of a plurality 
of access points of a private, local area network; 

b) an activatable telephone circuit for wireless commu- 
nication when activated with at least one of a plurality 
of cell sites of a public, cellular telephone network 
independent of the private network; and 

c) control means for activating one of the circuits to 
enable wireless communication with one of the inde- 
pendent networks by default, for determining a quality 
of the wireless communication between said one circuit 
and said one independent network, and for automati- 
cally activating the other of the circuits to enable 
wireless communication with the other of the indepen- 
dent networks upon a determination that the quality of 
the wireless communication between said one circuit 
and said one independent network has satisfied a pre- 
determined switching criterion. 

2. The device of claim 1, wherein the wireless commu- 
nication is at radio frequency. 

3. The device of claim 1, wherein the private network 
includes a plurality of hardware units located within a 
limited geographic area and sharing a common communi- 
cations line. 

4. The device of claim 1, wherein the private network is 
operative under IEEE 802.11 standard. 

5. The device of claim 1, wherein the private network is 
operative under an Internet Protocol (IP) to convey voice 
and data in IP packets. 

6. The device of claim 1, wherein the control means 
activates the transceiver circuit by default to enable wireless 
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communication with the private network when the device is 
located within an operating range relative to said at least one 
access point, and activates the telephone circuit to enable 
wireless communication with the public network when the 
device is located out of said operating range. 

7. The device of claim 6, wherein the control means 
determines said quality by determining communications 
reliability during movement of the device. 

8. The device of claim 6, wherein the control means 
activates the telephone circuit by default to enable wireless 
communication with the public network, and activates the 
transceiver circuit to enable wireless communication with 
the private network upon the determination that said quality 
has degraded. 

9. The device of claim 1, wherein the device includes a 
hand-held housing supportable by a user, a microphone on 
the housing for transmitting voice communication via the 
public network, and a speaker on the housing for providing 
audible sound via the public network. 

10. The device of claim 9, wherein the device includes a 
display on the housing for displaying information. 

11. A method of communicating with a mobile commu- 
nications device, comprising the steps of: 

a) providing an activatable transceiver circuit in the 
device for wireless communication when activated 
with at least one of a plurality of access points of a 
private, local area network; 

b) providing an activatable telephone circuit in the device 
for wireless communication when activated with at 
least one of a plurality of cell sites of a public, cellular 
telephone network independent of the private network; 
and 

c) activating one of the circuits to enable wireless com- 
munication with one of the independent networks by 
default, determining a quality of the wireless commu- 
nication between said one circuit and said one inde- 
pendent network, and automatically activating the other 
of the circuits to enable wireless communication with 
the other of the independent networks upon a determi- 
nation that the quality of the wireless communication 
between said one circuit and said one independent 
network has satisfied a predetermined switching crite- 
rion. 

12. The method of claim 11, wherein the wireless com- 
munication is at radio frequency. 

13. The method of claim 11, wherein the private network 
includes a plurality of hardware units located within a 
limited geographic area and sharing a common communi- 
cations line. 

14. The method of claim 11, wherein the private network 
is operative under IEEE 802.11 standard. 

15. The method of claim 11, wherein the private network 
is operative under an Internet Protocol (IP) to convey voice 
and data in IP packets. 

16. The method of claim 11, wherein the activating step 
is performed by activating the transceiver circuit by default 
to enable wireless communication with the private network 
when the device is located within an operating range relative 
to said at least one access point, and by activating the 
telephone circuit to enable wireless communication with the 
public network when the device is located out of said 
operating range. 

17. The method of claim 16, wherein the determining step 
is performed by determining said quality by determining 
communications reliability during movement of the device. 

18. The method of claim 16, wherein the activating step 
is performed by activating the telephone circuit by default to 
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enable wireless communication with the public network, and 
by activating the transceiver circuit to enable wireless com- 
munication with the private network upon the determination 
that said quality has degraded. 

19. The method of claim 11, wherein the device includes 
a hand-held housing supportable by a user; and further 
comprising the steps of providing a microphone on the 
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housing for transmitting voice communication via the public 
network, and a speaker on the housing for providing audible 
sound via the public network. 

20. The method of claim 19, and further comprising the 
step of displaying information on the housing. 
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